Subject: Re: Direct SSL connection with ALPN and HBA rules

From: Jacob Champion <[email-masked]>
Date: Thu, 25 Apr 2024 16:23:59 -0700

On Thu, Apr 25, 2024 at 2:50 PM Heikki Linnakangas <[email-masked]> wrote:
> > I think that comes down to the debate upthread, and whether you think
> > it's a performance tweak or a security feature. My take on it is,
> > `direct` mode is performance, and `requiredirect` is security.
>
> Agreed, although the the security benefits from `requiredirect` are
> pretty vague. It reduces the attack surface, but there are no known
> issues with the 'postgres' or 'direct' negotiation either.

I think reduction in attack surface is a concrete security benefit,
not a vague one. True, I don't know of any exploits today, but that
seems almost tautological -- if there were known exploits in our
upgrade handshake, I assume we'd be working to fix them ASAP?

> Perhaps 'requiredirect' should be renamed to 'directonly'?

If it's agreed that we don't want to require a stronger sslmode for
that sslnegotiation setting, then that would probably be an
improvement. But who is the target user for
`sslnegotiation=directonly`, in your opinion? Would they ever have a
reason to use a weak sslmode?

> >> I'm not sure about this either. The 'gssencmode' option is already
> >> quite weird in that it seems to override the "require"d priority of
> >> "sslmode=require", which it IMO really shouldn't.
>
> Yeah, that combination is weird. I think we should forbid it. But that's
> separate from sslnegotiation.

Separate but related, IMO. If we were all hypothetically okay with
gssencmode ignoring `sslmode=require`, then it's hard for me to claim
that `sslnegotiation=requiredirect` should behave differently. On the
other hand, if we're not okay with that and we'd like to change it,
it's easier for me to argue that `requiredirect` should also be
stricter from the get-go.

Thanks,
--Jacob

---

From: Heikki Linnakangas <[email-masked]>
Date: Mon, 29 Apr 2024 11:38:17 +0300

> upgrade handshake, I assume we'd be working to fix them ASAP?

Sure, we'd try to fix them ASAP. But we've had the SSLRequest 
negotiation since time immemorial. If a new vulnerability is found, it's 
unlikely that we'd need to disable the SSLRequest negotiation altogether 
to fix it. We'd be in serious trouble with back-branches in that case. 
There's no sudden need to have a kill-switch for it.

Taking that to the extreme, you could argue for a kill-switch for every 
feature, just in case there's a vulnerability in them. I agree that 
authentication is more sensitive so reducing the surface of that is more 
reasonable. And but nevertheless.

(This discussion is moot though, because we do have the 
sslnegotiation=requiredirect mode, so you can disable the SSLRequest 
negotiation.)

> reason to use a weak sslmode?

It's unlikely, I agree. A user who's sophisticated enough to use 
sslnegotiation=directonly would probably also want sslmode=require and 
require_auth=scram-sha256 and channel_binding=require. Or 
sslmode=verify-full. But in principle they're orthogonal. If you only 
have v17 servers in your environment, so you know all servers support 
direct negotiation if they support SSL at all, but a mix of servers with 
and without SSL, sslnegotiation=directonly would reduce roundtrips with 
sslmode=prefer.

Making requiredirect to imply sslmode=require, or error out unless you 
also set sslmode=require, feels like a cavalier way of forcing SSL. We 
should have a serious discussion on making sslmode=require the default 
instead. That would be a more direct way of nudging people to use SSL. 
It would cause a lot of breakage, but it would also be a big improvement 
to security.

Consider how sslnegotiation=requiredirect/directonly would feel, if we 
made sslmode=require the default. If you explicitly set "sslmode=prefer" 
or "sslmode=disable", it would be annoying if you would also need to 
remove "sslnegotiation=requiredirect" from your connection string.

I'm leaning towards renaming sslnegotiation=requiredirect to 
sslnegotiation=directonly at this point.

> stricter from the get-go.

I think the best way forward for those is something like a new 
"require_proto" parameter that you suggested upthread. Perhaps call it 
"encryption", with options "none", "ssl", "gss" so that you can provide 
multiple options and libpq will try them in the order specified. For 
example:

encryption=none
encryption=ssl, none  # like sslmode=prefer
encryption=gss
encryption=gss, ssl   # try GSS first, then SSL
encryption=ssl, gss   # try SSL first, then GSS

This would make gssencmode and sslmode=disable/allow/prefer/require 
settings obsolete. sslmode would stil be needed to distinguish between 
verify-ca/verify-full though. But sslnegotiation would be still 
orthogonal to that.

-- 
Heikki Linnakangas
Neon (https://neon.tech)

---

From: Robert Haas <[email-masked]>
Date: Mon, 29 Apr 2024 08:38:22 -0400

> remove "sslnegotiation=requiredirect" from your connection string.

I think making sslmode=require the default is pretty unworkable,
unless we also had a way of automatically setting up SSL as part of
initdb or something. Otherwise, we'd have to add sslmode=disable to a
million places just to get the regression tests to work, and every
test cluster anyone spins up locally would break in annoying ways,
too. I had been thinking we might want to change the default to
sslmode=disable and remove allow and prefer, but maybe automating a
basic SSL setup is better. Either way, we should move toward a world
where you either ask for SSL and get it, or don't ask for it and don't
get it. Being halfway in between is bad.

-- 
Robert Haas
EDB: http://www.enterprisedb.com

---

From: Jacob Champion <[email-masked]>
Date: Mon, 29 Apr 2024 11:43:04 -0700

> There's no sudden need to have a kill-switch for it.

I'm not really arguing that you'd need the kill switch to fix a
problem in the code. (At least, I'm not arguing that in this thread; I
reserve the right to argue that in the future. :D) But between the
point of time that a vulnerability is announced and a user has
upgraded, it's really nice to have a switch as a mitigation. Even
better if it's server-side, because then the DBA can protect all their
clients without requiring action on their part.

> reasonable. And but nevertheless.

I mean... that would be extreme, yeah. I don't think anyone's proposed that.

> If you only

But if you're in that situation, what does the use of directonly give
you over `sslnegotiation=direct`? You already know that servers
support direct, so there's no additional performance penalty from the
less strict mode.

> remove "sslnegotiation=requiredirect" from your connection string.

That's similar to how sslrootcert=system already works. To me, it
feels great, because I don't have to worry about nonsensical
combinations (with the exception of GSS, which we've touched on
above). libpq complains loudly if I try to shoot myself in the foot,
and if I'm using sslrootcert=system then it's a pretty clear signal
that I care more about security than the temporary inconvenience of
editing my connection string for one weird server that doesn't use SSL
for some reason.

> verify-ca/verify-full though. But sslnegotiation would be still

I will give this some more thought.

Thanks,
--Jacob

---

From: Heikki Linnakangas <[email-masked]>
Date: Mon, 29 Apr 2024 22:06:27 +0300

> support direct, so there's no additional performance penalty from the

Well, by that argument we don't need requiredirect/directonly at all. 
This goes back to whether it's a security feature or a performance feature.

There is a small benefit with sslmode=prefer if you connect to a server 
that doesn't support SSL, though. With sslnegotiation=direct, if the 
server rejects the direct SSL connection, the client will reconnect and 
try SSL with SSLRequest. The server will respond with 'N', and the 
client will proceed without encryption. sslnegotiation=directonly 
removes that SSLRequest attempt, eliminating one roundtrip.

> editing my connection string for one weird server that doesn't use SSL

Oh I was not aware sslrootcert=system works like that. That's a bit 
surprising, none of the other ssl-related settings imply or require that 
SSL is actually used. Did we intend to set a precedence for new settings 
with that?

(adding Daniel in case he has an opinion)

-- 
Heikki Linnakangas
Neon (https://neon.tech)

---

From: Jacob Champion <[email-masked]>
Date: Mon, 29 Apr 2024 12:32:36 -0700

> This goes back to whether it's a security feature or a performance feature.

That's what I've been trying to argue, yeah. If it's not a security
feature... why's it there?

> removes that SSLRequest attempt, eliminating one roundtrip.

Okay, agreed that in this case, there is a performance benefit. It's
not enough to convince me, honestly, but are there any other cases I
missed as well?

> SSL is actually used.

For sslrootcert=system in particular, the danger of accidentally weak
sslmodes is pretty high, especially for verify-ca mode. (It goes back
to that other argument -- there should be, effectively, zero users who
both opt in to the public CA system, and are also okay with silently
falling back and not using it.)

> Did we intend to set a precedence for new settings
> with that?

(I'll let committers answer whether they intended that or not -- I was
just bringing up that we already have a setting that works like that,
and I really like how it works in practice. But it's probably
unsurprising that I like it.)

--Jacob

---

From: Jacob Champion <[email-masked]>
Date: Mon, 29 Apr 2024 12:34:18 -0700

> feature... why's it there?

Er, I should clarify this. I _want_ requiredirect. I just want it to
be a security feature.

--Jacob

---

From: Daniel Gustafsson <[email-masked]>
Date: Tue, 30 Apr 2024 12:10:38 +0200

> On 29 Apr 2024, at 21:06, Heikki Linnakangas <[email-masked]> wrote:

> Oh I was not aware sslrootcert=system works like that. That's a bit surprising, none of the other ssl-related settings imply or require that SSL is actually used. Did we intend to set a precedence for new settings with that?

It was very much intentional, and documented, an sslmode other than verify-full
makes little sense when combined with sslrootcert=system.  It wasn't intended
to set a precedence (though there is probably a fair bit of things we can do,
getting this right is hard enough as it is), rather it was footgun prevention.

--
Daniel Gustafsson

---

From: Heikki Linnakangas <[email-masked]>
Date: Fri, 10 May 2024 16:50:32 +0300

> not enough to convince me, honestly, but are there any other cases I

I realized one case that hasn't been discussed so far: If you use the 
combination of "sslmode=prefer sslnegotiation=requiredirect" to connect 
to a pre-v17 server that has SSL enabled but does not support direct SSL 
connections, you will fall back to a plaintext connection instead. 
That's almost certainly not what you wanted. I'm coming around to your 
opinion that we should not allow that combination.

Stepping back to summarize my thoughts, there are now three things I 
don't like about the status quo:

1. As noted above, the sslmode=prefer and sslnegotiation=requiredirect 
combination is somewhat dangerous, as you might unintentionally fall 
back to plaintext authentication when connecting to a pre-v17 server.

2. There is an asymmetry between "postgres" and "direct"
option names. "postgres" means "try only traditional negotiation", while
"direct" means "try direct first, and fall back to traditional
negotiation if it fails". That is apparent only if you know that the
"requiredirect" mode also exists.

3. The "require" word in "requiredirect" suggests that it's somehow
more strict or more secure, similar to sslmode=require. However, I don't 
consider direct SSL connections to be a security feature.

New proposal:

- Remove the "try both" mode completely, and rename "requiredirect" to 
just "direct". So there would be just two modes: "postgres" and 
"direct". On reflection, the automatic fallback mode doesn't seem very 
useful. It would make sense as the default, because then you would get 
the benefits automatically in most cases but still be compatible with 
old servers. But if it's not the default, you have to fiddle with libpq 
settings anyway to enable it, and then you might as well use the 
"requiredirect" mode when you know the server supports it. There isn't 
anything wrong with it as such, but given how much confusion there's 
been on how this all works, I'd prefer to cut this back to the bare 
minimum now. We can add it back in the future, and perhaps make it the 
default at the same time. This addresses points 2. and 3. above.

and:

- Only allow sslnegotiation=direct with sslmode=require or higher. This 
is what you, Jacob, wanted to do all along, and addresses point 1.

Thoughts?

-- 
Heikki Linnakangas
Neon (https://neon.tech)

---

From: Jelte Fennema-Nio <[email-masked]>
Date: Sat, 11 May 2024 22:45:38 +0200

> is what you, Jacob, wanted to do all along, and addresses point 1.

Sounds mostly good to me. But I think we'd want to automatically
increase sslmode to require if it is unset, but sslnegotation is set
to direct. Similar to how we bump sslmode to verify-full if
sslrootcert is set to system, but sslmode is unset. i.e. it seems
unnecessary/unwanted to throw an error if the connection string only
contains sslnegotiation=direct

---

From: Heikki Linnakangas <[email-masked]>
Date: Mon, 13 May 2024 00:39:07 +0300

> contains sslnegotiation=direct

I find that error-prone. For example:

1. Try to connect to a server with direct negotiation: psql "host=foobar 
dbname=mydb sslnegotiation=direct"

2. It fails. Maybe it was an old server? Let's change it to 
sslnegotiation=postgres.

3. Now it succeeds. Great!

You might miss that by changing sslnegotiation to 'postgres', or by 
removing it altogether, you not only made it compatible with older 
server versions, but you also allowed falling back to a plaintext 
connection. Maybe you're fine with that, but maybe not. I'd like to 
nudge people to use sslmode=require, not rely on implicit stuff like 
this just to make connection strings a little shorter.

I'm not a fan of sslrootcert=system implying sslmode=verify-full either, 
for the same reasons. But at least "sslrootcert" is a clearly 
security-related setting, so removing it might give you a pause, whereas 
sslnegotition is about performance and compatibility.

In v18, I'd like to make sslmode=require the default. Or maybe introduce 
a new setting like "encryption=ssl|gss|none", defaulting to 'ssl'. If we 
want to encourage encryption, that's the right way to do it. (I'd still 
recommend everyone to use an explicit sslmode=require in their 
connection strings for many years, though, because you might be using an 
older client without realizing it.)

-- 
Heikki Linnakangas
Neon (https://neon.tech)

---

From: Jelte Fennema-Nio <[email-masked]>
Date: Mon, 13 May 2024 11:50:59 +0200

> this just to make connection strings a little shorter.

I understand your worry, but I'm not sure that this is actually much
of a security issue in practice. sslmode=prefer and sslmode=require
are the same amount of insecure imho (i.e. extremely insecure). The
only reason sslmode=prefer would connect as non-ssl to a server that
supports ssl is if an attacker has write access to the network in the
middle (i.e. eavesdropping ability alone is not enough). Once an
attacker has this level of network access, it's trivial for this
attacker to read any data sent to Postgres by intercepting the TLS
handshake and doing TLS termination with some arbitrary cert (any cert
is trusted by sslmode=require).

So the only actual case where this is a security issue I can think of
is when an attacker has only eavesdropping ability on the network. And
somehow the Postgres server that the client tries to connect to is
configured incorrectly, so that no ssl is set up at all. Then a client
would drop to plaintext, when connecting to this server instead of
erroring, and the attacker could now read the traffic. But I don't
really see this scenario end up any differently when requiring people
to enter sslmode=require. The only action a user can take to connect
to a server that does not have ssl support is to remove
sslmode=require from the connection string. Except if they are also
the server operator, in which case they could enable ssl on the
server. But if ssl is not set up, then it was probably never set up,
and thus providing sslnegotiation=direct would be to test if ssl
works.

But, if you disagree I'm fine with erroring on plain sslnegotiation=direct

> older client without realizing it.)

I'm definitely a huge proponent of making the connection defaults more
secure. But as described above sslmode=require is still extremely
insecure and I don't think we gain anything substantial by making it
the default. I think the only useful secure default would be to use
sslmode=verify-full (with probably some automatic fallback to
sslmode=prefer when connecting to hardcoded IPs or localhost). Which
probably means that sslrootcert=system should also be made the
default. Which would mean that ~/.postgresql/root.crt would not be the
default anymore, which I personally think is fine but others likely
disagree.

---

From: Heikki Linnakangas <[email-masked]>
Date: Mon, 13 May 2024 14:07:53 +0300

> default anymore, which I personally think is fine but others likely

"channel_binding=require sslmode=require" also protects from MITM attacks.

I think these options should be designed from the user's point of view, 
so that the user can specify the risks they're willing to accept, and 
the details of how that's accomplished are handled by libpq. For 
example, I'm OK with (tick all that apply):

[ ] passive eavesdroppers seeing all the traffic
[ ] MITM being able to hijack the session
[ ] connecting without verifying the server's identity
[ ] divulging the plaintext password to the server
[ ] ...

The requirements for whether SSL or GSS encryption is required, whether 
the server's certificate needs to signed with known CA, etc. can be 
derived from those. For example, if you need protection from 
eavesdroppers, SSL or GSS encryption must be used. If you need to verify 
the server's identity, it implies sslmode=verify-CA or 
channel_binding=true. If you don't want to divulge the password, it 
implies a suitable require_auth setting. I don't have a concrete 
proposal yet, but something like that. And the defaults for those are up 
for debate.

psql could perhaps help by listing the above properties at the beginning 
of the session, something like:

psql (16.2)
WARNING: Connection is not encrypted.
WARNING: The server's identity has not been verified
Type "help" for help.

postgres=#

Although for the "divulge plaintext password to server" property, it's 
too late to print a warning after connecting, because the damage has 
already been done.

A different line of thought is that to keep the attack surface as smal 
as possible, you should specify very explicitly what exactly you expect 
to happen in the authentication, and disallow any variance. For example, 
you expect SCRAM to be used, with a certificate signed by a particular 
CA, and if the server requests anything else, that's suspicious and the 
connection is aborted. We should make that possible too, but the above 
flexible risk-based approach seems good for the defaults.

-- 
Heikki Linnakangas
Neon (https://neon.tech)

---

From: Heikki Linnakangas <[email-masked]>
Date: Mon, 13 May 2024 16:37:50 +0300

> is what you, Jacob, wanted to do all along, and addresses point 1.

Here's a patch to implement that.

-- 
Heikki Linnakangas
Neon (https://neon.tech)
From 2a7bde8502966a634b62d4109f0cde5fdc685da2 Mon Sep 17 00:00:00 2001
From: Heikki Linnakangas <[email-masked]>
Date: Mon, 13 May 2024 16:36:54 +0300
Subject: [PATCH 1/1] Remove option to fall back from direct to postgres SSL
 negotiation

There were three problems with the sslnegotiation options:

1. The sslmode=prefer and sslnegotiation=requiredirect combination was
somewhat dangerous, as you might unintentionally fall back to
plaintext authentication when connecting to a pre-v17 server.

2. There was an asymmetry between 'postgres' and 'direct'
options. 'postgres' meant "try only traditional negotiation", while
'direct' meant "try direct first, and fall back to traditional
negotiation if it fails". That was apparent only if you knew that the
'requiredirect' mode also exists.

3. The "require" word in 'requiredirect' suggests that it's somehow
more strict or more secure, similar to sslmode. However, I don't
consider direct SSL connections to be a security feature.

To address these problems:

- Only allow sslnegotiation='direct' if sslmode='require' or
stronger. And for the record, Jacob and Robert felt that we should do
that (or have sslnegotiation='direct' imply sslmode='require') anyway,
regardless of the first issue.

- Remove the 'direct' mode that falls back to traditional negotiation,
and rename what was called 'requiredirect' to 'direct' instead. In
other words, there is no "try both methods" option anymore, 'postgres'
now means the traditional negotiation and 'direct' means a direct SSL
connection.

Discussion: https://www.postgresql.org/message-id/d3b1608a-a1b6-4eda-9ec5-ddb3e4375808%40iki.fi
---
 doc/src/sgml/libpq.sgml                       |  49 ++--
 src/interfaces/libpq/fe-connect.c             |  52 ++--
 src/interfaces/libpq/libpq-int.h              |   3 +-
 .../libpq/t/005_negotiate_encryption.pl       | 254 ++++++++----------
 4 files changed, 150 insertions(+), 208 deletions(-)

diff --git a/doc/src/sgml/libpq.sgml b/doc/src/sgml/libpq.sgml
index 1d32c226d8..b32e497b1b 100644
--- a/doc/src/sgml/libpq.sgml
+++ b/doc/src/sgml/libpq.sgml
@@ -1772,15 +1772,18 @@ postgresql://%2Fvar%2Flib%2Fpostgresql/dbname
       <term><literal>sslnegotiation</literal></term>
       <listitem>
        <para>
-        This option controls whether <productname>PostgreSQL</productname>
-        will perform its protocol negotiation to request encryption from the
-        server or will just directly make a standard <acronym>SSL</acronym>
-        connection.  Traditional <productname>PostgreSQL</productname>
-        protocol negotiation is the default and the most flexible with
-        different server configurations. If the server is known to support
-        direct <acronym>SSL</acronym> connections then the latter requires one
-        fewer round trip reducing connection latency and also allows the use
-        of protocol agnostic SSL network tools.
+        This option controls how SSL encryption is negotiated with the server,
+        if SSL is used. In the default <literal>postgres</literal> mode, the
+        client first asks the server if SSL is supported. In
+        <literal>direct</literal> mode, the client starts the standard SSL
+        handshake directly after establishing the TCP/IP connection. Traditional
+        <productname>PostgreSQL</productname> protocol negotiation is the most
+        flexible with different server configurations. If the server is known
+        to support direct <acronym>SSL</acronym> connections then the latter
+        requires one fewer round trip reducing connection latency and also
+        allows the use of protocol agnostic SSL network tools. The direct SSL
+        option was introduced in <productname>PostgreSQL</productname> version
+        17.
        </para>
 
         <variablelist>
@@ -1798,32 +1801,14 @@ postgresql://%2Fvar%2Flib%2Fpostgresql/dbname
           <term><literal>direct</literal></term>
           <listitem>
            <para>
-             first attempt to establish a standard SSL connection and if that
-             fails reconnect and perform the negotiation. This fallback
-             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
+             start SSL handshake directly after establishing the TCP/IP
+             connection.  This is only allowed with sslmode=require or higher,
+             because the weaker settings could lead to unintended fallback to
+             plaintext authentication when the server does not support direct
              SSL handshake.
            </para>
           </listitem>
          </varlistentry>
-
-         <varlistentry>
-          <term><literal>requiredirect</literal></term>
-          <listitem>
-           <para>
-             attempt to establish a standard SSL connection and if that fails
-             return a connection failure immediately.
-           </para>
-          </listitem>
-         </varlistentry>
         </variablelist>
       </listitem>
      </varlistentry>
@@ -2064,7 +2049,7 @@ postgresql://%2Fvar%2Flib%2Fpostgresql/dbname
         connections without having to decrypt the SSL stream.  (Note that
         unless the proxy is aware of the PostgreSQL protocol handshake this
         would require setting <literal>sslnegotiation</literal>
-        to <literal>direct</literal> or <literal>requiredirect</literal>.)
+        to <literal>direct</literal>.)
         However, <acronym>SNI</acronym> makes the destination host name appear
         in cleartext in the network traffic, so it might be undesirable in
         some cases.
diff --git a/src/interfaces/libpq/fe-connect.c b/src/interfaces/libpq/fe-connect.c
index 81d278c395..4a5a71de4b 100644
--- a/src/interfaces/libpq/fe-connect.c
+++ b/src/interfaces/libpq/fe-connect.c
@@ -274,7 +274,7 @@ static const internalPQconninfoOption PQconninfoOptions[] = {
 	offsetof(struct pg_conn, sslmode)},
 
 	{"sslnegotiation", "PGSSLNEGOTIATION", DefaultSSLNegotiation, NULL,
-		"SSL-Negotiation", "", 14,	/* sizeof("requiredirect") == 14 */
+		"SSL-Negotiation", "", 9,	/* sizeof("postgres") == 9  */
 	offsetof(struct pg_conn, sslnegotiation)},
 
 	{"sslcompression", "PGSSLCOMPRESSION", "0", NULL,
@@ -1590,8 +1590,7 @@ pqConnectOptions2(PGconn *conn)
 	if (conn->sslnegotiation)
 	{
 		if (strcmp(conn->sslnegotiation, "postgres") != 0
-			&& strcmp(conn->sslnegotiation, "direct") != 0
-			&& strcmp(conn->sslnegotiation, "requiredirect") != 0)
+			&& strcmp(conn->sslnegotiation, "direct") != 0)
 		{
 			conn->status = CONNECTION_BAD;
 			libpq_append_conn_error(conn, "invalid %s value: \"%s\"",
@@ -1608,6 +1607,25 @@ pqConnectOptions2(PGconn *conn)
 			return false;
 		}
 #endif
+
+		/*
+		 * Don't allow direct SSL negotiation with sslmode='prefer', because
+		 * that poses a risk of unintentional fallback to plaintext connection
+		 * when connecting to a pre-v17 server that does not support direct
+		 * SSL connections. To keep things simple, don't allow it with
+		 * sslmode='allow' or sslmode='disable' either. If a user goes through
+		 * the trouble of setting sslnegotiation='direct', they probably
+		 * intend to use SSL, and sslmode=disable or allow is probably a user
+		 * user mistake anyway.
+		 */
+		if (conn->sslnegotiation[0] == 'd' &&
+			conn->sslmode[0] != 'r' && conn->sslmode[0] != 'v')
+		{
+			conn->status = CONNECTION_BAD;
+			libpq_append_conn_error(conn, "weak sslmode \"%s\" may not be used with sslnegotiation=direct (use \"require\", \"verify-ca\", or \"verify-full\")",
+									conn->sslmode);
+			return false;
+		}
 	}
 	else
 	{
@@ -4312,8 +4330,6 @@ init_allowed_encryption_methods(PGconn *conn)
 		if (conn->sslnegotiation[0] == 'p')
 			conn->allowed_enc_methods |= ENC_NEGOTIATED_SSL;
 		else if (conn->sslnegotiation[0] == 'd')
-			conn->allowed_enc_methods |= ENC_DIRECT_SSL | ENC_NEGOTIATED_SSL;
-		else if (conn->sslnegotiation[0] == 'r')
 			conn->allowed_enc_methods |= ENC_DIRECT_SSL;
 	}
 #endif
@@ -4376,18 +4392,6 @@ connection_failed(PGconn *conn)
 	Assert((conn->failed_enc_methods & conn->current_enc_method) == 0);
 	conn->failed_enc_methods |= conn->current_enc_method;
 
-	/*
-	 * If the server reported an error after the SSL handshake, no point in
-	 * retrying with negotiated vs direct SSL.
-	 */
-	if ((conn->current_enc_method & (ENC_DIRECT_SSL | ENC_NEGOTIATED_SSL)) != 0 &&
-		conn->ssl_handshake_started)
-	{
-		conn->failed_enc_methods |= (ENC_DIRECT_SSL | ENC_NEGOTIATED_SSL) & conn->allowed_enc_methods;
-	}
-	else
-		conn->failed_enc_methods |= conn->current_enc_method;
-
 	return select_next_encryption_method(conn, false);
 }
 
@@ -4449,20 +4453,8 @@ select_next_encryption_method(PGconn *conn, bool have_valid_connection)
 	if (conn->sslmode[0] == 'a')
 		SELECT_NEXT_METHOD(ENC_PLAINTEXT);
 
-	/*
-	 * If enabled, try direct SSL. Unless we have a valid TCP connection that
-	 * 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, negotiated SSL is not
-	 * in the list of allowed methods and we will reconnect.)
-	 */
-	if (have_valid_connection)
-		SELECT_NEXT_METHOD(ENC_NEGOTIATED_SSL);
-
-	SELECT_NEXT_METHOD(ENC_DIRECT_SSL);
 	SELECT_NEXT_METHOD(ENC_NEGOTIATED_SSL);
+	SELECT_NEXT_METHOD(ENC_DIRECT_SSL);
 
 	if (conn->sslmode[0] != 'a')
 		SELECT_NEXT_METHOD(ENC_PLAINTEXT);
diff --git a/src/interfaces/libpq/libpq-int.h b/src/interfaces/libpq/libpq-int.h
index 3691e5ee96..10d2709869 100644
--- a/src/interfaces/libpq/libpq-int.h
+++ b/src/interfaces/libpq/libpq-int.h
@@ -395,8 +395,7 @@ struct pg_conn
 	char	   *keepalives_count;	/* maximum number of TCP keepalive
 									 * retransmits */
 	char	   *sslmode;		/* SSL mode (require,prefer,allow,disable) */
-	char	   *sslnegotiation; /* SSL initiation style
-								 * (postgres,direct,requiredirect) */
+	char	   *sslnegotiation; /* SSL initiation style (postgres,direct) */
 	char	   *sslcompression; /* SSL compression (0 or 1) */
 	char	   *sslkey;			/* client key filename */
 	char	   *sslcert;		/* client certificate filename */
diff --git a/src/interfaces/libpq/t/005_negotiate_encryption.pl b/src/interfaces/libpq/t/005_negotiate_encryption.pl
index 03a9079f3f..36ba8aede8 100644
--- a/src/interfaces/libpq/t/005_negotiate_encryption.pl
+++ b/src/interfaces/libpq/t/005_negotiate_encryption.pl
@@ -209,7 +209,7 @@ $node->reload;
 my @all_test_users = ('testuser', 'ssluser', 'nossluser', 'gssuser', 'nogssuser');
 my @all_gssencmodes = ('disable', 'prefer', 'require');
 my @all_sslmodes = ('disable', 'allow', 'prefer', 'require');
-my @all_sslnegotiations = ('postgres', 'direct', 'requiredirect');
+my @all_sslnegotiations = ('postgres', 'direct');
 
 my $server_config = {
 	server_ssl => 0,
@@ -223,23 +223,22 @@ my $test_table;
 if ($ssl_supported) {
 	$test_table = q{
 # USER      GSSENCMODE   SSLMODE      SSLNEGOTIATION EVENTS                      -> OUTCOME
-testuser    disable      disable      *              connect, authok             -> plain
-.           .            allow        *              connect, authok             -> plain
+testuser    disable      disable      postgres       connect, authok             -> plain
+.           .            allow        postgres       connect, authok             -> plain
 .           .            prefer       postgres       connect, sslreject, authok  -> plain
-.           .            .            direct         connect, directsslreject, reconnect, sslreject, authok  -> plain
-.           .            .            requiredirect  connect, directsslreject, reconnect, authok -> plain
 .           .            require      postgres       connect, sslreject          -> fail
-.           .            .            direct         connect, directsslreject, reconnect, sslreject -> fail
-.           .            .            requiredirect  connect, directsslreject    -> fail
-.           prefer       disable      *              connect, authok             -> plain
-.           .            allow        *              connect, authok             -> plain
+.           .            .            direct         connect, directsslreject    -> fail
+.           prefer       disable      postgres       connect, authok             -> plain
+.           .            allow        postgres       connect, authok             -> plain
 .           .            prefer       postgres       connect, sslreject, authok  -> plain
-.           .            .            direct         connect, directsslreject, reconnect, sslreject, authok  -> plain
-.           .            .            requiredirect  connect, directsslreject, reconnect, authok -> plain
 .           .            require      postgres       connect, sslreject          -> fail
-.           .            .            direct         connect, directsslreject, reconnect, sslreject -> fail
-.           .            .            requiredirect  connect, directsslreject    -> fail
-	};
+.           .            .            direct         connect, directsslreject    -> fail
+
+# sslnegotiation=direct is not acccepted unless sslmode=require or stronger
+*           *            disable      direct         -     -> fail
+*           *            allow        direct         -     -> fail
+*           *            prefer       direct         -     -> fail
+};
 } else {
 	# Compiled without SSL support
 	$test_table = q{
@@ -251,11 +250,10 @@ testuser    disable      disable      postgres       connect, authok
 .           .            allow        postgres       connect, authok             -> plain
 .           .            prefer       postgres       connect, authok             -> plain
 
-# Without SSL support, sslmode=require and sslnegotiation=direct/requiredirect
-# are not accepted at all.
-.           *            require      *              -     -> fail
-.           *            *            direct         -     -> fail
-.           *            *            requiredirect  -     -> fail
+# Without SSL support, sslmode=require and sslnegotiation=direct are
+# not accepted at all
+*           *            require      *              -     -> fail
+*           *            *            direct         -     -> fail
 	};
 }
 
@@ -281,34 +279,26 @@ SKIP:
 
 	$test_table = q{
 # USER      GSSENCMODE   SSLMODE      SSLNEGOTIATION EVENTS                                          -> OUTCOME
-testuser    disable      disable      *              connect, authok                                 -> plain
-.           .            allow        *              connect, authok                                 -> plain
+testuser    disable      disable      postgres       connect, authok                                 -> plain
+.           .            allow        postgres       connect, authok                                 -> plain
 .           .            prefer       postgres       connect, sslaccept, authok                      -> ssl
-.           .            .            direct         connect, directsslaccept, authok                -> ssl
-.           .            .            requiredirect  connect, directsslaccept, authok                -> ssl
 .           .            require      postgres       connect, sslaccept, authok                      -> ssl
 .           .            .            direct         connect, directsslaccept, authok                -> ssl
-.           .            .            requiredirect  connect, directsslaccept, authok                -> ssl
-ssluser     .            disable      *              connect, authfail                               -> fail
+ssluser     .            disable      postgres       connect, authfail                               -> fail
 .           .            allow        postgres       connect, authfail, reconnect, sslaccept, authok -> ssl
-.           .            .            direct         connect, authfail, reconnect, directsslaccept, authok -> ssl
-.           .            .            requiredirect  connect, authfail, reconnect, directsslaccept, authok -> ssl
 .           .            prefer       postgres       connect, sslaccept, authok                      -> ssl
-.           .            .            direct         connect, directsslaccept, authok                -> ssl
-.           .            .            requiredirect  connect, directsslaccept, authok                -> ssl
 .           .            require      postgres       connect, sslaccept, authok                      -> ssl
 .           .            .            direct         connect, directsslaccept, authok                -> ssl
-.           .            .            requiredirect  connect, directsslaccept, authok                -> ssl
-nossluser   .            disable      *              connect, authok                                 -> plain
+nossluser   .            disable      postgres       connect, authok                                 -> plain
 .           .            allow        postgres       connect, authok                                 -> plain
-.           .            .            direct         connect, authok                                 -> plain
-.           .            .            requiredirect  connect, authok                                 -> plain
 .           .            prefer       postgres       connect, sslaccept, authfail, reconnect, authok -> plain
-.           .            .            direct         connect, directsslaccept, authfail, reconnect, authok -> plain
-.           .            .            requiredirect  connect, directsslaccept, authfail, reconnect, authok -> plain
 .           .            require      postgres       connect, sslaccept, authfail                    -> fail
 .           .            require      direct         connect, directsslaccept, authfail              -> fail
-.           .            require      requiredirect  connect, directsslaccept, authfail              -> fail
+
+# sslnegotiation=direct is not acccepted unless sslmode=require or stronger
+*           *            disable      direct         -     -> fail
+*           *            allow        direct         -     -> fail
+*           *            prefer       direct         -     -> fail
 };
 
 	# Enable SSL in the server
@@ -342,62 +332,54 @@ SKIP:
 
 	$test_table = q{
 # USER      GSSENCMODE   SSLMODE      SSLNEGOTIATION EVENTS                       -> OUTCOME
-testuser    disable      disable      *              connect, authok              -> plain
-.           .            allow        *              connect, authok              -> plain
+testuser    disable      disable      postgres       connect, authok              -> plain
+.           .            allow        postgres       connect, authok              -> plain
 .           .            prefer       postgres       connect, sslreject, authok   -> plain
-.           .            .            direct         connect, directsslreject, reconnect, sslreject, authok  -> plain
-.           .            .            requiredirect  connect, directsslreject, reconnect, authok             -> plain
 .           .            require      postgres       connect, sslreject                -> fail
-.           .            .            direct         connect, directsslreject, reconnect, sslreject -> fail
-.           .            .            requiredirect  connect, directsslreject          -> fail
-.           prefer       *            *              connect, gssaccept, authok        -> gss
-.           require      *            *              connect, gssaccept, authok        -> gss
+.           .            .            direct         connect, directsslreject          -> fail
+.           prefer       *            postgres       connect, gssaccept, authok        -> gss
+.           prefer       require      direct         connect, gssaccept, authok        -> gss
+.           require      *            postgres       connect, gssaccept, authok        -> gss
+.           .            require      direct         connect, gssaccept, authok        -> gss
 
-gssuser     disable      disable      *              connect, authfail                  -> fail
+gssuser     disable      disable      postgres       connect, authfail                  -> fail
 .           .            allow        postgres       connect, authfail, reconnect, sslreject -> fail
-.           .            .            direct         connect, authfail, reconnect, directsslreject, reconnect, sslreject -> fail
-.           .            .            requiredirect  connect, authfail, reconnect, directsslreject -> fail
 .           .            prefer       postgres       connect, sslreject, authfail       -> fail
-.           .            .            direct         connect, directsslreject, reconnect, sslreject, authfail -> fail
-.           .            .            requiredirect  connect, directsslreject, reconnect, authfail -> fail
 .           .            require      postgres       connect, sslreject                 -> fail
-.           .            .            direct         connect, directsslreject, reconnect, sslreject -> fail
-.           .            .            requiredirect  connect, directsslreject           -> fail
-.           prefer       *            *              connect, gssaccept, authok   -> gss
-.           require      *            *              connect, gssaccept, authok   -> gss
+.           .            .            direct         connect, directsslreject           -> fail
+.           prefer       *            postgres       connect, gssaccept, authok   -> gss
+.           prefer       require      direct         connect, gssaccept, authok   -> gss
+.           require      *            postgres       connect, gssaccept, authok   -> gss
+.           .            require      direct         connect, gssaccept, authok   -> gss
 
-nogssuser   disable      disable      *              connect, authok              -> plain
+nogssuser   disable      disable      postgres       connect, authok              -> plain
 .           .            allow        postgres       connect, authok              -> plain
-.           .            .            direct         connect, authok              -> plain
-.           .            .            requiredirect  connect, authok              -> plain
 .           .            prefer       postgres       connect, sslreject, authok   -> plain
-.           .            .            direct         connect, directsslreject, reconnect, sslreject, authok   -> plain
-.           .            .            requiredirect  connect, directsslreject, reconnect, authok              -> plain
 .           .            require      postgres       connect, sslreject                 -> fail
-.           .            .            direct         connect, directsslreject, reconnect, sslreject -> fail
-.           .            .            requiredirect  connect, directsslreject           -> fail
-.           prefer       disable      *              connect, gssaccept, authfail, reconnect, authok             -> plain
+.           .            .            direct         connect, directsslreject           -> fail
+.           prefer       disable      postgres       connect, gssaccept, authfail, reconnect, authok             -> plain
 .           .            allow        postgres       connect, gssaccept, authfail, reconnect, authok             -> plain
-.           .            .            direct         connect, gssaccept, authfail, reconnect, authok             -> plain
-.           .            .            requiredirect  connect, gssaccept, authfail, reconnect, authok             -> plain
 .           .            prefer       postgres       connect, gssaccept, authfail, reconnect, sslreject, authok  -> plain
-.           .            .            direct         connect, gssaccept, authfail, reconnect, directsslreject, reconnect, sslreject, authok  -> plain
-.           .            .            requiredirect  connect, gssaccept, authfail, reconnect, directsslreject, reconnect, authok  -> plain
 .           .            require      postgres       connect, gssaccept, authfail, reconnect, sslreject          -> fail
-.           .            .            direct         connect, gssaccept, authfail, reconnect, directsslreject, reconnect, sslreject          -> fail
-.           .            .            requiredirect  connect, gssaccept, authfail, reconnect, directsslreject          -> fail
-.           require      disable      *              connect, gssaccept, authfail -> fail
-.           .            allow        *              connect, gssaccept, authfail -> fail
-.           .            prefer       *              connect, gssaccept, authfail -> fail
-.           .            require      *              connect, gssaccept, authfail -> fail   # If both GSSAPI and sslmode are required, and GSS is not available -> fail
+.           .            .            direct         connect, gssaccept, authfail, reconnect, directsslreject          -> fail
+.           require      disable      postgres       connect, gssaccept, authfail -> fail
+.           .            allow        postgres       connect, gssaccept, authfail -> fail
+.           .            prefer       postgres       connect, gssaccept, authfail -> fail
+.           .            require      postgres       connect, gssaccept, authfail -> fail   # If both GSSAPI and sslmode are required, and GSS is not available -> fail
+.           .            .            direct         connect, gssaccept, authfail -> fail   # If both GSSAPI and sslmode are required, and GSS is not available -> fail
+
+# sslnegotiation=direct is not acccepted unless sslmode=require or stronger
+*           *            disable      direct         -     -> fail
+*           *            allow        direct         -     -> fail
+*           *            prefer       direct         -     -> fail
 	};
 
 	# The expected events and outcomes above assume that SSL support
 	# is enabled. When libpq is compiled without SSL support, all
 	# attempts to connect with sslmode=require or
-	# sslnegotiation=direct/requiredirect would fail immediately without
-	# even connecting to the server. Skip those, because we tested
-	# them earlier already.
+	# sslnegotiation=direct would fail immediately without even
+	# connecting to the server. Skip those, because we tested them
+	# earlier already.
 	my ($sslmodes, $sslnegotiations);
 	if ($ssl_supported != 0) {
 		($sslmodes, $sslnegotiations) = (\@all_sslmodes, \@all_sslnegotiations);
@@ -431,100 +413,84 @@ SKIP:
 
 	$test_table = q{
 # USER      GSSENCMODE   SSLMODE      SSLNEGOTIATION EVENTS                       -> OUTCOME
-testuser    disable      disable      *              connect, authok              -> plain
-.           .            allow        *              connect, authok              -> plain
-.           .            prefer       postgres       connect, sslaccept, authok         -> ssl
-.           .            .            direct         connect, directsslaccept, authok   -> ssl
-.           .            .            requiredirect  connect, directsslaccept, authok   -> ssl
-.           .            require      postgres       connect, sslaccept, authok         -> ssl
+testuser    disable      disable      postgres       connect, authok              -> plain
+.           .            allow        postgres       connect, authok              -> plain
+.           .            prefer       postgres       connect, sslaccept, authok   -> ssl
+.           .            require      postgres       connect, sslaccept, authok   -> ssl
 .           .            .            direct         connect, directsslaccept, authok   -> ssl
-.           .            .            requiredirect  connect, directsslaccept, authok   -> ssl
-.           prefer       disable      *              connect, gssaccept, authok   -> gss
-.           .            allow        *              connect, gssaccept, authok   -> gss
-.           .            prefer       *              connect, gssaccept, authok   -> gss
-.           .            require      *              connect, gssaccept, authok   -> gss     # If both GSS and SSL is possible, GSS is chosen over SSL, even if sslmode=require
-.           require      disable      *              connect, gssaccept, authok   -> gss
-.           .            allow        *              connect, gssaccept, authok   -> gss
-.           .            prefer       *              connect, gssaccept, authok   -> gss
-.           .            require      *              connect, gssaccept, authok   -> gss     # If both GSS and SSL is possible, GSS is chosen over SSL, even if sslmode=require
-
-gssuser     disable      disable      *              connect, authfail            -> fail
+.           prefer       disable      postgres       connect, gssaccept, authok   -> gss
+.           .            allow        postgres       connect, gssaccept, authok   -> gss
+.           .            prefer       postgres       connect, gssaccept, authok   -> gss
+.           .            require      postgres       connect, gssaccept, authok   -> gss     # If both GSS and SSL is possible, GSS is chosen over SSL, even if sslmode=require
+.           .            .            direct         connect, gssaccept, authok   -> gss
+.           require      disable      postgres       connect, gssaccept, authok   -> gss
+.           .            allow        postgres       connect, gssaccept, authok   -> gss
+.           .            prefer       postgres       connect, gssaccept, authok   -> gss
+.           .            require      postgres       connect, gssaccept, authok   -> gss     # If both GSS and SSL is possible, GSS is chosen over SSL, even if sslmode=require
+.           .            .            direct         connect, gssaccept, authok   -> gss
+
+gssuser     disable      disable      postgres       connect, authfail            -> fail
 .           .            allow        postgres       connect, authfail, reconnect, sslaccept, authfail -> fail
-.           .            .            direct         connect, authfail, reconnect, directsslaccept, authfail -> fail
-.           .            .            requiredirect  connect, authfail, reconnect, directsslaccept, authfail -> fail
 .           .            prefer       postgres       connect, sslaccept, authfail, reconnect, authfail -> fail
-.           .            .            direct         connect, directsslaccept, authfail, reconnect, authfail -> fail
-.           .            .            requiredirect  connect, directsslaccept, authfail, reconnect, authfail -> fail
 .           .            require      postgres       connect, sslaccept, authfail       -> fail
 .           .            .            direct         connect, directsslaccept, authfail -> fail
-.           .            .            requiredirect  connect, directsslaccept, authfail -> fail
-.           prefer       disable      *              connect, gssaccept, authok   -> gss
-.           .            allow        *              connect, gssaccept, authok   -> gss
-.           .            prefer       *              connect, gssaccept, authok   -> gss
-.           .            require      *              connect, gssaccept, authok   -> gss   # GSS is chosen over SSL, even though sslmode=require
-.           require      disable      *              connect, gssaccept, authok   -> gss
-.           .            allow        *              connect, gssaccept, authok   -> gss
-.           .            prefer       *              connect, gssaccept, authok   -> gss
-.           .            require      *              connect, gssaccept, authok   -> gss     # If both GSS and SSL is possible, GSS is chosen over SSL, even if sslmode=require
-
-ssluser     disable      disable      *              connect, authfail            -> fail
+.           prefer       disable      postgres       connect, gssaccept, authok   -> gss
+.           .            allow        postgres       connect, gssaccept, authok   -> gss
+.           .            prefer       postgres       connect, gssaccept, authok   -> gss
+.           .            require      postgres       connect, gssaccept, authok   -> gss   # GSS is chosen over SSL, even though sslmode=require
+.           .            .            direct         connect, gssaccept, authok   -> gss
+.           require      disable      postgres       connect, gssaccept, authok   -> gss
+.           .            allow        postgres       connect, gssaccept, authok   -> gss
+.           .            prefer       postgres       connect, gssaccept, authok   -> gss
+.           .            require      postgres       connect, gssaccept, authok   -> gss     # If both GSS and SSL is possible, GSS is chosen over SSL, even if sslmode=require
+.           .            .            direct         connect, gssaccept, authok   -> gss
+
+ssluser     disable      disable      postgres       connect, authfail            -> fail
 .           .            allow        postgres       connect, authfail, reconnect, sslaccept, authok       -> ssl
-.           .            .            direct         connect, authfail, reconnect, directsslaccept, authok -> ssl
-.           .            .            requiredirect  connect, authfail, reconnect, directsslaccept, authok -> ssl
 .           .            prefer       postgres       connect, sslaccept, authok         -> ssl
-.           .            .            direct         connect, directsslaccept, authok   -> ssl
-.           .            .            requiredirect  connect, directsslaccept, authok   -> ssl
 .           .            require      postgres       connect, sslaccept, authok         -> ssl
 .           .            .            direct         connect, directsslaccept, authok   -> ssl
-.           .            .            requiredirect  connect, directsslaccept, authok   -> ssl
-.           prefer       disable      *              connect, gssaccept, authfail, reconnect, authfail -> fail
+.           prefer       disable      postgres       connect, gssaccept, authfail, reconnect, authfail -> fail
 .           .            allow        postgres       connect, gssaccept, authfail, reconnect, authfail, reconnect, sslaccept, authok       -> ssl
-.           .            .            direct         connect, gssaccept, authfail, reconnect, authfail, reconnect, directsslaccept, authok -> ssl
-.           .            .            requiredirect  connect, gssaccept, authfail, reconnect, authfail, reconnect, directsslaccept, authok -> ssl
 .           .            prefer       postgres       connect, gssaccept, authfail, reconnect, sslaccept, authok       -> ssl
-.           .            .            direct         connect, gssaccept, authfail, reconnect, directsslaccept, authok -> ssl
-.           .            .            requiredirect  connect, gssaccept, authfail, reconnect, directsslaccept, authok -> ssl
 .           .            require      postgres       connect, gssaccept, authfail, reconnect, sslaccept, authok       -> ssl
 .           .            .            direct         connect, gssaccept, authfail, reconnect, directsslaccept, authok -> ssl
-.           .            .            requiredirect  connect, gssaccept, authfail, reconnect, directsslaccept, authok -> ssl
-.           require      disable      *              connect, gssaccept, authfail -> fail
-.           .            allow        *              connect, gssaccept, authfail -> fail
-.           .            prefer       *              connect, gssaccept, authfail -> fail
-.           .            require      *              connect, gssaccept, authfail -> fail         # If both GSS and SSL are required, the sslmode=require is effectively ignored and GSS is required
+.           require      disable      postgres       connect, gssaccept, authfail -> fail
+.           .            allow        postgres       connect, gssaccept, authfail -> fail
+.           .            prefer       postgres       connect, gssaccept, authfail -> fail
+.           .            require      postgres       connect, gssaccept, authfail -> fail         # If both GSS and SSL are required, the sslmode=require is effectively ignored and GSS is required
+.           .            .            direct         connect, gssaccept, authfail -> fail
 
-nogssuser   disable      disable      *              connect, authok              -> plain
+nogssuser   disable      disable      postgres       connect, authok              -> plain
 .           .            allow        postgres       connect, authok              -> plain
-.           .            .            direct         connect, authok              -> plain
-.           .            .            requiredirect  connect, authok              -> plain
 .           .            prefer       postgres       connect, sslaccept, authok   -> ssl
-.           .            .            direct         connect, directsslaccept, authok   -> ssl
-.           .            .            requiredirect  connect, directsslaccept, authok   -> ssl
 .           .            require      postgres       connect, sslaccept, authok   -> ssl
 .           .            .            direct         connect, directsslaccept, authok   -> ssl
-.           .            .            requiredirect  connect, directsslaccept, authok   -> ssl
-.           prefer       disable      *              connect, gssaccept, authfail, reconnect, authok              -> plain
-.           .            allow        *              connect, gssaccept, authfail, reconnect, authok              -> plain
+.           prefer       disable      postgres       connect, gssaccept, authfail, reconnect, authok              -> plain
+.           .            allow        postgres       connect, gssaccept, authfail, reconnect, authok              -> plain
 .           .            prefer       postgres       connect, gssaccept, authfail, reconnect, sslaccept, authok         -> ssl
-.           .            .            direct         connect, gssaccept, authfail, reconnect, directsslaccept, authok   -> ssl
-.           .            .            requiredirect  connect, gssaccept, authfail, reconnect, directsslaccept, authok   -> ssl
 .           .            require      postgres       connect, gssaccept, authfail, reconnect, sslaccept, authok         -> ssl
 .           .            .            direct         connect, gssaccept, authfail, reconnect, directsslaccept, authok   -> ssl
-.           .            .            requiredirect  connect, gssaccept, authfail, reconnect, directsslaccept, authok   -> ssl
-.           require      disable      *              connect, gssaccept, authfail -> fail
-.           .            allow        *              connect, gssaccept, authfail -> fail
-.           .            prefer       *              connect, gssaccept, authfail -> fail
-.           .            require      *              connect, gssaccept, authfail -> fail   # If both GSS and SSL are required, the sslmode=require is effectively ignored and GSS is required
-
-nossluser   disable      disable      *              connect, authok              -> plain
-.           .            allow        *              connect, authok              -> plain
+.           require      disable      postgres       connect, gssaccept, authfail -> fail
+.           .            allow        postgres       connect, gssaccept, authfail -> fail
+.           .            prefer       postgres       connect, gssaccept, authfail -> fail
+.           .            require      postgres       connect, gssaccept, authfail -> fail   # If both GSS and SSL are required, the sslmode=require is effectively ignored and GSS is required
+.           .            .            direct         connect, gssaccept, authfail -> fail
+
+nossluser   disable      disable      postgres       connect, authok              -> plain
+.           .            allow        postgres       connect, authok              -> plain
 .           .            prefer       postgres       connect, sslaccept, authfail, reconnect, authok       -> plain
-.           .            .            direct         connect, directsslaccept, authfail, reconnect, authok -> plain
-.           .            .            requiredirect  connect, directsslaccept, authfail, reconnect, authok -> plain
 .           .            require      postgres       connect, sslaccept, authfail       -> fail
 .           .            .            direct         connect, directsslaccept, authfail -> fail
-.           .            .            requiredirect  connect, directsslaccept, authfail -> fail
-.           prefer       *            *              connect, gssaccept, authok   -> gss
-.           require      *            *              connect, gssaccept, authok   -> gss
+.           prefer       *            postgres       connect, gssaccept, authok   -> gss
+.           .            require      direct         connect, gssaccept, authok   -> gss
+.           require      *            postgres       connect, gssaccept, authok   -> gss
+.           .            require      direct         connect, gssaccept, authok   -> gss
+
+# sslnegotiation=direct is not acccepted unless sslmode=require or stronger
+*           *            disable      direct         -     -> fail
+*           *            allow        direct         -     -> fail
+*           *            prefer       direct         -     -> fail
 	};
 
 	note("Running tests with both GSS and SSL enabled in server");
-- 
2.39.2

---

From: Jelte Fennema-Nio <[email-masked]>
Date: Mon, 13 May 2024 15:55:48 +0200

I think these checks should use strcmp instead of checking magic first
characters. I see this same clever trick is used in the recently added
init_allowed_encryption_methods, and I think that should be changed to
use strcmp too for readability.

---

From: Jelte Fennema-Nio <[email-masked]>
Date: Mon, 13 May 2024 16:19:36 +0200

> "channel_binding=require sslmode=require" also protects from MITM attacks.

Cool, I didn't realize we had this connection option and it could be
used like this. But I think there's a few security downsides of
channel_binding=require over sslmode=verify-full: If the client relies
on channel_binding to validate server authenticity, a leaked
server-side SCRAM hash is enough for an attacker to impersonate a
server. While normally a leaked scram hash isn't really much of a
security concern (assuming long enough passwords). I also don't know
of many people rotating their scram hashes, even though many rotate
TLS certs.

> [ ] divulging the plaintext password to the server

I think that sounds like a great idea, looking forward to the proposal.

---

From: Heikki Linnakangas <[email-masked]>
Date: Mon, 13 May 2024 17:54:30 +0300

> use strcmp too for readability.

Oh yeah, I hate that too. These should be refactored into enums, with a 
clear separate stage of parsing the options from strings. But we use 
that pattern all over the place, so I didn't want to start reforming it 
with this patch.

-- 
Heikki Linnakangas
Neon (https://neon.tech)

---

From: Robert Haas <[email-masked]>
Date: Mon, 13 May 2024 12:13:32 -0400

> Here's a patch to implement that.

I find this idea to be a massive improvement over the status quo, and
I didn't spot any major problems when I read through the patch,
either. I'm not quite sure if the patch takes the right approach in
emphasizing that weaker sslmode settings are not allowed because of
unintended fallbacks. It seems to me that we could equally well say
that those combinations are nonsensical. If we're making a direct SSL
connection, SSL is eo ipso required.

I don't have a strong opinion about whether sslnegotiation=direct
should error out (as you propose here) or silently promote sslmode to
require. I think either is defensible. Had I been implementing it, I
think I would have done as Jacob proposes, just because once we've
forced a direct SSL negotiation surely the only sensible behavior is
to be using SSL, unless you think there should be a
silently-reconnect-without-SSL behavior, which I sure don't. However,
I disagree with Jacob's assertion that sslmode=require has no security
benefits over sslmode=prefer. That seems like the kind of pessimism
that makes people hate security professionals. There have got to be
some attacks that are foreclosed by encrypting the connection, even if
you don't stop MITM attacks or other things that are more
sophisticated than running wireshark and seeing what goes by on the
wire.

I'm pleased to hear that you will propose to make sslmode=require the
default in v18. I think we'll need to do some work to figure out how
much collateral damage that will cause, and maybe it will be more than
we can stomach, but Magnus has been saying for years that the current
default is terrible. I'm not sure I was entirely convinced of that the
first time I heard him say it, but I'm smarter now than I was then.
It's really hard to believe in 2024 that anyone should ever be using a
setting that may or may not encrypt the connection. There's http and
https but there's no httpmaybes.

---

From: Jacob Champion <[email-masked]>
Date: Mon, 13 May 2024 09:45:27 -0700

(There's, uh, a lot to respond to above and I'm trying to figure out
how best to type up all of it.)

On Mon, May 13, 2024 at 9:13 AM Robert Haas <[email-masked]> wrote:
> However,
> benefits over sslmode=prefer.

For the record, I didn't say that... You mean Jelte's quote up above?:

> sslmode=prefer and sslmode=require
> are the same amount of insecure imho (i.e. extremely insecure).

I agree that requiring passive security is tangibly better than
allowing fallback to plaintext. I think Jelte's point might be better
stated as, =prefer and =require give the same amount of protection
against active attack (none).

--Jacob

---

From: Jelte Fennema-Nio <[email-masked]>
Date: Mon, 13 May 2024 19:41:58 +0200

> sophisticated than running wireshark and seeing what goes by on the

Like Jacob already said, I guess you meant me here. The main point I
was trying to make is that sslmode=require is extremely insecure too,
so if we're changing the default then I'd rather bite the bullet and
actually make the default a secure one this time. No-ones browser
trusts self-signed certs by default, but currently lots of people
trust self-signed certs when connecting to their production database
without realizing.

IMHO the only benefit that sslmode=require brings over sslmode=prefer
is detecting incorrectly configured servers i.e. servers that are
supposed to support ssl but somehow don't due to a misconfigured
GUC/pg_hba. Such "incorrectly configured server" detection avoids
sending data to such a server, which an eavesdropper on the network
could see. Which is definitely a security benefit, but it's an
extremely small one. In all other cases sslmode=prefer brings exactly
the same protection as sslmode=require, because sslmode=prefer
encrypts the connection unless postgres actively tells the client to
downgrade to plaintext (which never happens when the server is
configured correctly).

---

From: Jacob Champion <[email-masked]>
Date: Mon, 13 May 2024 11:09:50 -0700

[soapbox thread, so I've changed the Subject]

> "channel_binding=require sslmode=require" also protects from MITM attacks.

This isn't true in the same way that "standard" TLS protects against
MITM. I know you know that, but for the benefit of bystanders reading
the threads, I think we should stop phrasing it like this. Most people
who want MITM protection need to be using verify-full.

Details for those bystanders: Channel binding alone will only
disconnect you after the MITM is discovered, after your startup packet
is leaked but before you send any queries to the server. A hash of
your password will also be leaked in that situation, which starts the
timer on an offline attack. And IIRC, you won't get an alert that says
"someone's in the middle"; it'll just look like you mistyped your
password.

(Stronger passwords provide stronger protection in this situation,
which is not a property that most people are used to. If I choose to
sign into Google with the password "hunter2", it doesn't somehow make
the TLS protection weaker. But if you rely on SCRAM by itself for
server authentication, it does more or less work like that.)

Use channel_binding *in addition to* sslmode=verify-full if you want
enhanced authentication of the peer, as suggested in the docs [1].
Don't rely on channel binding alone for the vast majority of use
cases, and if you know better for your particular use case, then you
already know enough to be able to ignore my advice.

[/soapbox]

Thanks,
--Jacob

[1] https://www.postgresql.org/docs/current/preventing-server-spoofing.html

---

From: Robert Haas <[email-masked]>
Date: Mon, 13 May 2024 15:12:48 -0400

On Mon, May 13, 2024 at 12:45 PM Jacob Champion
<[email-masked]> wrote:
> For the record, I didn't say that... You mean Jelte's quote up above?

Yeah, sorry, I got my J-named hackers confused. Apologies.

---

From: Robert Haas <[email-masked]>
Date: Mon, 13 May 2024 15:24:32 -0400

> downgrade to plaintext (which never happens when the server is

I think I agree with *nearly* every word of this. However:

(1) I don't want to hijack this thread about a v17 open item to talk
too much about a hypothetical v18 proposal.

(2) While in general you need more than just SSL to ensure security,
I'm not sure that there's only one way to do it, and I doubt that we
should try to pick a winner.

(3) I suspect that even going as far as sslmode=require by default is
going to be extremely painful for hackers, the project, and users.
Moving the goalposts further increases the likelihood of nothing
happening at all.

---

From: Jacob Champion <[email-masked]>
Date: Mon, 13 May 2024 15:29:17 -0700

On Mon, May 13, 2024 at 9:13 AM Robert Haas <[email-masked]> wrote:
> I find this idea to be a massive improvement over the status quo,

+1

> and
> either.

Definitely not a major problem, but I think
select_next_encryption_method() has gone stale, since it originally
provided generality and lines of fallback that no longer exist. In
other words, I think the following code is now misleading:

> SELECT_NEXT_METHOD(ENC_DIRECT_SSL);
>

To me, that implies that negotiated mode takes precedence over direct,
but the point of the patch is that it's not possible to have both. And
if direct SSL is in use, then sslmode can't be "allow" anyway, and we
definitely don't want ENC_PLAINTEXT.

So if someone proposes a change to select_next_encryption_method(),
you'll have to remember to stare at init_allowed_encryption_methods()
as well, and think really hard about what's going on. And vice-versa.
That worries me.

> require. I think either is defensible.

I'm comforted that, since sslrootcert=system already does it, plenty
of use cases will get that for free. And if you decide in the future
that you really really want it to promote, it won't be a compatibility
break to make that change. (That gives us more time for wider v16-17
adoption, to see how the sslrootcert=system magic promotion behavior
is going in practice.)

> Had I been implementing it, I
> silently-reconnect-without-SSL behavior, which I sure don't.

We still allow GSS to preempt SSL, though, so "forced" is probably
overstating things.

> https but there's no httpmaybes.

+1. I think (someone hop in and correct me please) that Opportunistic
Encryption for HTTP mostly fizzled, and they gave it a *lot* of
thought.

--Jacob

---

From: Jacob Champion <[email-masked]>
Date: Mon, 13 May 2024 17:05:41 -0700

[this should probably belong to a different thread, but I'm not sure
what to title it]

> [ ] divulging the plaintext password to the server

I'm pessimistic about a quality-of-protection scheme for this use case
(*). I don't think users need more knobs in their connection strings,
and many of the goals of transport encryption are really not
independent from each other in practice. As evidence I point to the
absolute mess of GSSAPI wrapping, which lets you check separate boxes
for things like "require the server to authenticate itself" and
"require integrity" and "allow MITMs to reorder messages" and so on,
as if the whole idea of "integrity" is useful if you don't know who
you're talking to in the first place. I think I recall slapd having
something similarly arcane (but at least it doesn't make the clients
do it!). Those kinds of APIs don't evolve well, in my opinion.

I think most people probably just want browser-grade security as
quickly and cheaply as possible, and we don't make that very easy
today. I'll try to review a QoP scheme if someone works on it, don't
get me wrong, but I'd much rather spend time on a "very secure by
default" mode that gets rid of most of the options (i.e. a
postgresqls:// scheme).

(*) I've proposed quality-of-protection in the past, for Postgres
proxy authentication [1]. But I'm comfortable in my hypocrisy, because
in that case, the end user doing the configuration is a DBA with a
config file who is expected to understand the whole system, and it's a
niche use case (IMO) without an obvious "common setup". And frankly I
think my proposal is unlikely to go anywhere; the cost/benefit
probably isn't good enough.

> If you need to verify
> channel_binding=true.

Neither of those two options provides strong authentication of the
peer, and personally I wouldn't want them to be considered worthy of
"verify the server's identity" mode.

And -- taking a wild leap here -- if we disagree, then granularity
becomes a problem: either the QoP scheme now has to have
sub-checkboxes for "if the server knows my password, that's good
enough" and "it's fine if the server's hostname doesn't match the
cert, for some reason", or it smashes all of those different ideas
into one setting and then I have to settle for the weakest common
denominator during an active attack. Assuming I haven't missed a third
option, will that be easier/better than the status quo of
require_auth+sslmode?

> connection is aborted. We should make that possible too

That's 'require_auth=scram-sha-256 sslmode=verify-ca', no?

--Jacob

[1] https://www.postgresql.org/message-id/0768cedb-695a-8841-5f8b-da2aa64c8f3a%40timescale.com

---

From: Heikki Linnakangas <[email-masked]>
Date: Wed, 15 May 2024 16:33:33 +0300

> as well, and think really hard about what's going on. And vice-versa.

Ok, yeah, I can see that now. Here's a new version to address that. I 
merged ENC_SSL_NEGOTIATED_SSL and ENC_SSL_DIRECT_SSL to a single method, 
ENC_SSL. The places that need to distinguish between them now check 
conn-sslnegotiation. That seems more clear now that there is no fallback.

-- 
Heikki Linnakangas
Neon (https://neon.tech)
From 7a2bc2ede5ba7bef147e509ce3c4d5472c8e0247 Mon Sep 17 00:00:00 2001
From: Heikki Linnakangas <[email-masked]>
Date: Wed, 15 May 2024 16:27:51 +0300
Subject: [PATCH v2 1/1] Remove option to fall back from direct to postgres SSL
 negotiation

Reviewed-by: Jelte Fennema-Nio, Robert Haas, Jacob Champion
Discussion: https://www.postgresql.org/message-id/d3b1608a-a1b6-4eda-9ec5-ddb3e4375808%40iki.fi
---
 doc/src/sgml/libpq.sgml                       |  49 ++--
 src/interfaces/libpq/fe-connect.c             | 144 +++++-----
 src/interfaces/libpq/fe-secure-openssl.c      |   2 +-
 src/interfaces/libpq/libpq-int.h              |   6 +-
 .../libpq/t/005_negotiate_encryption.pl       | 254 ++++++++----------
 5 files changed, 202 insertions(+), 253 deletions(-)

         <variablelist>
index 81d278c395..85f55b14a9 100644

@@ -3347,42 +3365,47 @@ keep_going:						/* We will come back to here until there is
 					goto error_return;
 
 				/*
-				 * If direct SSL is enabled, jump right into SSL handshake. We
-				 * will come back here after SSL encryption has been
-				 * established, with ssl_in_use set.
-				 */
-				if (conn->current_enc_method == ENC_DIRECT_SSL && !conn->ssl_in_use)
-				{
-					conn->status = CONNECTION_SSL_STARTUP;
-					return PGRES_POLLING_WRITING;
-				}
-
-				/*
-				 * If negotiated SSL is enabled, request SSL and proceed with
-				 * SSL handshake.  We will come back here after SSL encryption
-				 * has been established, with ssl_in_use set.
+				 * If SSL is enabled, start the SSL negotiation. We will come
+				 * back here after SSL encryption has been established, with
+				 * ssl_in_use set.
 				 */
-				if (conn->current_enc_method == ENC_NEGOTIATED_SSL && !conn->ssl_in_use)
+				if (conn->current_enc_method == ENC_SSL && !conn->ssl_in_use)
 				{
-					ProtocolVersion pv;
-
 					/*
-					 * Send the SSL request packet.
-					 *
-					 * Theoretically, this could block, but it really
-					 * shouldn't since we only got here if the socket is
-					 * write-ready.
+					 * If traditional postgres SSL negotiation is used, send
+					 * the SSL request.  In direct negotiation, jump straight
+					 * into the SSL handshake.
 					 */
-					pv = pg_hton32(NEGOTIATE_SSL_CODE);
-					if (pqPacketSend(conn, 0, &pv, sizeof(pv)) != STATUS_OK)
+					if (conn->sslnegotiation[0] == 'p')
 					{
-						libpq_append_conn_error(conn, "could not send SSL negotiation packet: %s",
-												SOCK_STRERROR(SOCK_ERRNO, sebuf, sizeof(sebuf)));
-						goto error_return;
+						ProtocolVersion pv;
+
+						Assert(conn->sslnegotiation[0] == 'p');
+
+						/*
+						 * Send the SSL request packet.
+						 *
+						 * Theoretically, this could block, but it really
+						 * shouldn't since we only got here if the socket is
+						 * write-ready.
+						 */
+						pv = pg_hton32(NEGOTIATE_SSL_CODE);
+						if (pqPacketSend(conn, 0, &pv, sizeof(pv)) != STATUS_OK)
+						{
+							libpq_append_conn_error(conn, "could not send SSL negotiation packet: %s",
+													SOCK_STRERROR(SOCK_ERRNO, sebuf, sizeof(sebuf)));
+							goto error_return;
+						}
+						/* Ok, wait for response */
+						conn->status = CONNECTION_SSL_STARTUP;
+						return PGRES_POLLING_READING;
+					}
+					else
+					{
+						Assert(conn->sslnegotiation[0] == 'd');
+						conn->status = CONNECTION_SSL_STARTUP;
+						return PGRES_POLLING_WRITING;
 					}
-					/* Ok, wait for response */
-					conn->status = CONNECTION_SSL_STARTUP;
-					return PGRES_POLLING_READING;
 				}
 #endif							/* USE_SSL */
 
@@ -3453,11 +3476,11 @@ keep_going:						/* We will come back to here until there is
 				PostgresPollingStatusType pollres;
 
 				/*
-				 * On first time through, get the postmaster's response to our
-				 * SSL negotiation packet. If we are trying a direct ssl
-				 * connection, go straight to initiating ssl.
+				 * On first time through with traditional SSL negotiation, get
+				 * the postmaster's response to our SSLRequest packet. With
+				 * sslnegotiation='direct', go straight to initiating SSL.
 				 */
-				if (!conn->ssl_in_use && conn->current_enc_method == ENC_NEGOTIATED_SSL)
+				if (!conn->ssl_in_use && conn->sslnegotiation[0] == 'p')
 				{
 					/*
 					 * We use pqReadData here since it has the logic to
@@ -4282,7 +4305,7 @@ init_allowed_encryption_methods(PGconn *conn)
 	if (conn->raddr.addr.ss_family == AF_UNIX)
 	{
 		/* Don't request SSL or GSSAPI over Unix sockets */
-		conn->allowed_enc_methods &= ~(ENC_DIRECT_SSL | ENC_NEGOTIATED_SSL | ENC_GSSAPI);
+		conn->allowed_enc_methods &= ~(ENC_SSL | ENC_GSSAPI);
 
 		/*
 		 * XXX: we probably should not do this. sslmode=require works
@@ -4309,12 +4332,7 @@ init_allowed_encryption_methods(PGconn *conn)
 	/* sslmode anything but 'disable', and GSSAPI not required */
 	if (conn->sslmode[0] != 'd' && conn->gssencmode[0] != 'r')
 	{
-		if (conn->sslnegotiation[0] == 'p')
-			conn->allowed_enc_methods |= ENC_NEGOTIATED_SSL;
-		else if (conn->sslnegotiation[0] == 'd')
-			conn->allowed_enc_methods |= ENC_DIRECT_SSL | ENC_NEGOTIATED_SSL;
-		else if (conn->sslnegotiation[0] == 'r')
-			conn->allowed_enc_methods |= ENC_DIRECT_SSL;
+		conn->allowed_enc_methods |= ENC_SSL;
 	}
 #endif
 
@@ -4354,7 +4372,8 @@ encryption_negotiation_failed(PGconn *conn)
 
 	if (select_next_encryption_method(conn, true))
 	{
-		if (conn->current_enc_method == ENC_DIRECT_SSL)
+		/* An existing connection cannot be reused for direct SSL */
+		if (conn->current_enc_method == ENC_SSL && conn->sslnegotiation[0] == 'd')
 			return 2;
 		else
 			return 1;
@@ -4376,18 +4395,6 @@ connection_failed(PGconn *conn)
 	Assert((conn->failed_enc_methods & conn->current_enc_method) == 0);
 	conn->failed_enc_methods |= conn->current_enc_method;
 
-	/*
 
@@ -4445,24 +4452,17 @@ select_next_encryption_method(PGconn *conn, bool have_valid_connection)
 	SELECT_NEXT_METHOD(ENC_GSSAPI);
 #endif
 
-	/* With sslmode=allow, try plaintext connection before SSL. */
-	if (conn->sslmode[0] == 'a')
-		SELECT_NEXT_METHOD(ENC_PLAINTEXT);
-
 	/*
-	 * If enabled, try direct SSL. Unless we have a valid TCP connection that
-	 * 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, negotiated SSL is not
-	 * in the list of allowed methods and we will reconnect.)
+	 * The order between SSL encryption and plaintext depends on sslmode. With
+	 * sslmode=allow, try plaintext connection before SSL. With
+	 * sslmode=prefer, it's the other way round. With other modes, we only try
+	 * plaintext or SSL connections so the order they're listed here doesn't
+	 * matter.
 	 */
-	if (have_valid_connection)
-		SELECT_NEXT_METHOD(ENC_NEGOTIATED_SSL);
+	if (conn->sslmode[0] == 'a')
+		SELECT_NEXT_METHOD(ENC_PLAINTEXT);
 
-	SELECT_NEXT_METHOD(ENC_DIRECT_SSL);
-	SELECT_NEXT_METHOD(ENC_NEGOTIATED_SSL);
+	SELECT_NEXT_METHOD(ENC_SSL);
 
 	if (conn->sslmode[0] != 'a')
 		SELECT_NEXT_METHOD(ENC_PLAINTEXT);
diff --git a/src/interfaces/libpq/fe-secure-openssl.c b/src/interfaces/libpq/fe-secure-openssl.c
index fb6bb911f5..bf9dfbf918 100644
--- a/src/interfaces/libpq/fe-secure-openssl.c
+++ b/src/interfaces/libpq/fe-secure-openssl.c
@@ -1586,7 +1586,7 @@ open_client_SSL(PGconn *conn)
 	}
 
 	/* ALPN is mandatory with direct SSL connections */
-	if (conn->current_enc_method == ENC_DIRECT_SSL)
+	if (conn->current_enc_method == ENC_SSL && conn->sslnegotiation[0] == 'd')
 	{
 		const unsigned char *selected;
 		unsigned int len;
diff --git a/src/interfaces/libpq/libpq-int.h b/src/interfaces/libpq/libpq-int.h
index 3691e5ee96..3886204c70 100644
--- a/src/interfaces/libpq/libpq-int.h
+++ b/src/interfaces/libpq/libpq-int.h
@@ -235,8 +235,7 @@ typedef enum
 #define ENC_ERROR			0
 #define ENC_PLAINTEXT		0x01
 #define ENC_GSSAPI			0x02
-#define ENC_DIRECT_SSL		0x04
-#define ENC_NEGOTIATED_SSL	0x08
+#define ENC_SSL				0x04
 
 /* Target server type (decoded value of target_session_attrs) */
 typedef enum
@@ -395,8 +394,7 @@ struct pg_conn
 	char	   *keepalives_count;	/* maximum number of TCP keepalive
 									 * retransmits */
 	char	   *sslmode;		/* SSL mode (require,prefer,allow,disable) */
-	char	   *sslnegotiation; /* SSL initiation style
-								 * (postgres,direct,requiredirect) */
+	char	   *sslnegotiation; /* SSL initiation style (postgres,direct) */
 	char	   *sslcompression; /* SSL compression (0 or 1) */
 	char	   *sslkey;			/* client key filename */
 	char	   *sslcert;		/* client certificate filename */
diff --git a/src/interfaces/libpq/t/005_negotiate_encryption.pl b/src/interfaces/libpq/t/005_negotiate_encryption.pl
index bc19cd244b..c3f70d31bc 100644
--- a/src/interfaces/libpq/t/005_negotiate_encryption.pl
+++ b/src/interfaces/libpq/t/005_negotiate_encryption.pl
@@ -213,7 +213,7 @@ my @all_test_users =
   ('testuser', 'ssluser', 'nossluser', 'gssuser', 'nogssuser');
 my @all_gssencmodes = ('disable', 'prefer', 'require');
 my @all_sslmodes = ('disable', 'allow', 'prefer', 'require');
-my @all_sslnegotiations = ('postgres', 'direct', 'requiredirect');
+my @all_sslnegotiations = ('postgres', 'direct');
 
 my $server_config = {
 	server_ssl => 0,
@@ -228,23 +228,22 @@ if ($ssl_supported)
 {
 	$test_table = q{
@@ -258,11 +257,10 @@ testuser    disable      disable      postgres       connect, authok

@@ -288,34 +286,26 @@ SKIP:
 
 	$test_table = q{
 
 	# Enable SSL in the server
@@ -350,62 +340,54 @@ SKIP:
 
 	$test_table = q{

 
 	if ($ssl_supported != 0)
 	{
@@ -445,100 +427,84 @@ SKIP:
 
 	$test_table = q{

---

From: Jacob Champion <[email-masked]>
Date: Wed, 15 May 2024 11:24:00 -0700

> conn-sslnegotiation. That seems more clear now that there is no fallback.

That change and the new comment that were added seem a lot clearer to
me, too; +1. And I like that this potentially preps for
encryption=gss/ssl/none or similar.

This assertion seems a little strange to me:

>                       ProtocolVersion pv;
>                       Assert(conn->sslnegotiation[0] == 'p');

But other than that nitpick, nothing else jumps out at me at the moment.

Thanks,
--Jacob

---

From: Robert Haas <[email-masked]>
Date: Thu, 16 May 2024 09:53:47 -0400

> conn-sslnegotiation. That seems more clear now that there is no fallback.

Unless there is a compelling reason to do otherwise, we should
expedite getting this committed so that it is included in beta1.
Release freeze begins Saturday.

Thanks,