On Sat, 18 Sep 2021 at 12:57, Thomas Habets <tho...@habets.se> wrote:
> > 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
