But these are two changes:
1. Actually verify against a CA
2. Actually check the CN/altnames
Anything short of "verify-full" is in my view "not checking". Even with a private CA this allows for a lot of lateral movement in an org, as if you have one cert you have them all, for impersonation purposes.
100% agree. I suspect that many postgres users are not completely aware that by default their ssl connections do not check the CA or CN/altnames.
Changing such a default is a big change.
Agreed. It is going to break existing installs that rely on the current behaviour.
There are two defaults to worry about here:
sslmode=prefer
sslrootcert=~/.postgresql/root.crt
Having sslrootcert use the system trust store if ~/.postgresql/root.crt doesn’t exist would seem like a good change.
Changing sslmode to default to something else would mostly likely break a ton of existing installations, and there are plenty of use cases were ssl isn’t used. Trying ssl first and without afterwards probably is still a sensible default. However…
I haven’t completely through this through, but what if the sslmode=prefer logic was:
1. Try ssl first, with both CA and CN checking (ie same as verify-full)
2. Print warnings appropriate to what type of ssl connection can be made
3. If all else fails, try without ssl.
In other words start with verify-full and downgrade gracefully to prefer, but actually tell the user that this has happen.
Essentially sslmode=prefer is a type of opportunistic encryption. I’m suggesting making it try stronger levels of ssl opportunistically. Require, verify-ca and verify-full can keep their semantics, or rather, they should all try verify-full first and then downgrade (with warnings logged) to the level they actually enforce.
Thanks
C
