Message-ID: <d3b1608a-a1b6-4eda-9ec5-ddb3e4375808@iki.fi>
Date: Fri, 10 May 2024 16:50:32 +0300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Direct SSL connection with ALPN and HBA rules
To: Jacob Champion <jacob.champion@enterprisedb.com>
Cc: Daniel Gustafsson <daniel@yesql.se>, Robert Haas <robertmhaas@gmail.com>,
 Michael Paquier <michael@paquier.xyz>,
 Postgres hackers <pgsql-hackers@lists.postgresql.org>
References: <ZiH7vHwEJeRKHlST@paquier.xyz>
 <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>
 <5a79ed71-b365-4b20-80bc-9c2bf97bf84b@iki.fi>
 <CAOYmi+kfsRfopQRTuJwpsO50Urq=-gwYDJ1fWNkDr3oYM1wdjA@mail.gmail.com>
 <CA+TgmoZspODpL6AYbANpffhbF+Q12xo1pHXrR9ZSkYfEQWpP3w@mail.gmail.com>
 <CAOYmi+k3x-aKiVzyLfzdxFdmcBmVD8UvcwfB075BkNqyA1aa9w@mail.gmail.com>
 <CA+TgmobR1R8q-rT06oWdLw_Kp_i67Uey9b+rWVrrpCJVSDNBFQ@mail.gmail.com>
 <CAOYmi+=TB8=yfXoBk=p0k0GPaCD79F8xXcypZFkjKmPKuT0hjQ@mail.gmail.com>
 <f6833e88-2e21-459d-a661-152ced273c60@iki.fi>
 <CAOYmi+nWKJNihuMpT+ZVTC5-d+pQdACTK7xKhhwAB075EHrOMg@mail.gmail.com>
 <3a6f126c-e1aa-4dcc-9252-9868308f6cf0@iki.fi>
 <CAOYmi+k2kJcJLMj=K4Vb3S_J6tN6989Wfi5+amqf15VkHcej3Q@mail.gmail.com>
 <1a717f65-7390-4111-8efd-c6e9b213805e@iki.fi>
 <CAOYmi+mAfO2hXfpOrpjhSZZf7Rq-rCywdyyfygkqbZ0KZjOBTg@mail.gmail.com>
Content-Language: en-US
From: Heikki Linnakangas <hlinnaka@iki.fi>
In-Reply-To: <CAOYmi+mAfO2hXfpOrpjhSZZf7Rq-rCywdyyfygkqbZ0KZjOBTg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <https://www.postgresql.org/message-id/d3b1608a-a1b6-4eda-9ec5-ddb3e4375808%40iki.fi>
Precedence: bulk

On 29/04/2024 22:32, Jacob Champion wrote:
> On Mon, Apr 29, 2024 at 12:06 PM Heikki Linnakangas <hlinnaka@iki.fi> wrote:
>> 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.
> 
> 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?

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)