public inbox for [email protected]
help / color / mirror / Atom feedFrom: Heikki Linnakangas <[email protected]>
To: Jacob Champion <[email protected]>
To: Robert Haas <[email protected]>
Cc: Michael Paquier <[email protected]>
Cc: Postgres hackers <[email protected]>
Subject: Re: Direct SSL connection with ALPN and HBA rules
Date: Wed, 24 Apr 2024 00:19:57 +0300
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAOYmi+=sj+1uydS0NR4nYzw-LRWp3Q-s5speBug5UCLSPMbvGA@mail.gmail.com>
References: <[email protected]>
<[email protected]>
<CAOYmi+kbYPX78nu0k7OODxUhoD6H1OXdugiMK1z9Nn33G-qdcQ@mail.gmail.com>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<CAOYmi+n57x+8DVi9J+dGmFQo+2Eb+bg_+geH=jqfh3E=NWHfOA@mail.gmail.com>
<CA+TgmoaLpDVY2ywqQUfxvKEQZ+nwkabcw_f=i4Zyivt9CLjcmA@mail.gmail.com>
<CAOYmi+=sj+1uydS0NR4nYzw-LRWp3Q-s5speBug5UCLSPMbvGA@mail.gmail.com>
On 23/04/2024 22:33, Jacob Champion wrote:
> On Tue, Apr 23, 2024 at 10:43 AM Robert Haas <[email protected]> wrote:
>> I've not followed this thread closely enough to understand the comment
>> about requiredirect maybe not actually requiring direct, but if that
>> were true it seems like it might be concerning.
>
> It may be my misunderstanding. This seems to imply bad behavior:
>
>> If the server rejects GSS encryption, SSL is
>> negotiated over the same TCP connection using the traditional postgres
>> protocol, regardless of <literal>sslnegotiation</literal>.
>
> As does this comment:
>
>> + /*
>> + * If enabled, try direct SSL. Unless we have a valid TCP connection that
>> + * failed negotiating GSSAPI encryption or a plaintext connection in case
>> + * of sslmode='allow'; in that case we prefer to reuse the connection with
>> + * negotiated SSL, instead of reconnecting to do direct SSL. The point of
>> + * direct SSL is to avoid the roundtrip from the negotiation, but
>> + * reconnecting would also incur a roundtrip.
>> + */
>
> but when I actually try those cases, I see that requiredirect does
> actually cause a direct SSL connection to be done, even with
> sslmode=allow. So maybe it's just misleading documentation (or my
> misreading of it) that needs to be expanded? Am I missing a different
> corner case where requiredirect is ignored, Heikki?
You're right, the comment is wrong about sslmode=allow. There is no
negotiation of a plaintext connection, the client just sends the startup
packet directly. The HBA rules can reject it, but the client will have
to disconnect and reconnect in that case.
The documentation and that comment are misleading about failed GSSAPI
encryption too, and I also misremembered that. With
sslnegotiation=requiredirect, libpq never uses negotiated SSL mode. It
will reconnect after a rejected GSSAPI request. So that comment applies
to sslnegotiation=direct, but not sslnegotiation=requiredirect.
Attached patch tries to fix and clarify those.
(Note that the client will only attempt GSSAPI encryption if it can find
kerberos credentials in the environment.)
--
Heikki Linnakangas
Neon (https://neon.tech)
Attachments:
[text/x-patch] 0001-Fix-documentation-and-comments-on-what-happens-after.patch (3.7K, ../[email protected]/2-0001-Fix-documentation-and-comments-on-what-happens-after.patch)
download | inline diff:
From 664555decb695123a4bf25ea56f789202b926ea0 Mon Sep 17 00:00:00 2001
From: Heikki Linnakangas <[email protected]>
Date: Wed, 24 Apr 2024 00:10:24 +0300
Subject: [PATCH 1/1] Fix documentation and comments on what happens after GSS
rejection
The paragraph in the docs and the comment applied to
sslnegotiaton=direct, but not sslnegotiation=requiredirect. In
'requiredirect' mode, negotiated SSL is never used. Move the paragraph
in the docs under the description of 'direct' mode, and rephrase it.
Also the comment's reference to reusing a plaintext connection was
bogus. Authentication failure in plaintext mode only happens after
sending the startup packet, so the connection cannot be reused.
---
doc/src/sgml/libpq.sgml | 19 +++++++++----------
src/interfaces/libpq/fe-connect.c | 11 ++++++-----
2 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/doc/src/sgml/libpq.sgml b/doc/src/sgml/libpq.sgml
index 9199d0d2e5..7f854edfa2 100644
--- a/doc/src/sgml/libpq.sgml
+++ b/doc/src/sgml/libpq.sgml
@@ -1803,6 +1803,15 @@ postgresql://%2Fvar%2Flib%2Fpostgresql/dbname
process adds significant latency if the initial SSL connection
fails.
</para>
+ <para>
+ An exception is if <literal>gssencmode</literal> is set
+ to <literal>prefer</literal>, but the server rejects GSS encryption.
+ In that case, SSL is negotiated over the same TCP connection using
+ <productname>PostgreSQL</productname> protocol negotiation. In
+ other words, the direct SSL handshake is not used, if a TCP
+ connection has already been established and can be used for the
+ SSL handshake.
+ </para>
</listitem>
</varlistentry>
@@ -1816,16 +1825,6 @@ postgresql://%2Fvar%2Flib%2Fpostgresql/dbname
</listitem>
</varlistentry>
</variablelist>
-
- <para>
- Note that if <literal>gssencmode</literal> is set
- to <literal>prefer</literal>, a <acronym>GSS</acronym> connection is
- attempted first. If the server rejects GSS encryption, SSL is
- negotiated over the same TCP connection using the traditional postgres
- protocol, regardless of <literal>sslnegotiation</literal>. In other
- words, the direct SSL handshake is not used, if a TCP connection has
- already been established and can be used for the SSL handshake.
- </para>
</listitem>
</varlistentry>
diff --git a/src/interfaces/libpq/fe-connect.c b/src/interfaces/libpq/fe-connect.c
index ec20e3f3a9..b1d3bfa59d 100644
--- a/src/interfaces/libpq/fe-connect.c
+++ b/src/interfaces/libpq/fe-connect.c
@@ -4430,11 +4430,12 @@ select_next_encryption_method(PGconn *conn, bool have_valid_connection)
/*
* If enabled, try direct SSL. Unless we have a valid TCP connection that
- * failed negotiating GSSAPI encryption or a plaintext connection in case
- * of sslmode='allow'; in that case we prefer to reuse the connection with
- * negotiated SSL, instead of reconnecting to do direct SSL. The point of
- * direct SSL is to avoid the roundtrip from the negotiation, but
- * reconnecting would also incur a roundtrip.
+ * failed negotiating GSSAPI encryption; in that case we prefer to reuse
+ * the connection with negotiated SSL, instead of reconnecting to do
+ * direct SSL. The point of sslnegotiation=direct is to avoid the
+ * roundtrip from the negotiation, but reconnecting would also incur a
+ * roundtrip. (In sslnegotiation=requiredirect mode, negotiatied SSL is
+ * not in the list of allowed methods and we will reconnect.)
*/
if (have_valid_connection)
SELECT_NEXT_METHOD(ENC_NEGOTIATED_SSL);
--
2.39.2
view thread (28+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: Direct SSL connection with ALPN and HBA rules
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox