Re: [PATCH] Add `verify-system` sslmode to use system CA pool for server cert

On Sat, 18 Sep 2021 at 12:57, Thomas Habets <thomas@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