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