Re: Direct SSL connection with ALPN and HBA rules

On 13/05/2024 12:50, Jelte Fennema-Nio wrote:
> On Sun, 12 May 2024 at 23:39, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
>> 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.)
> 
> 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.

"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)