On Tue, Oct 03, 2017 at 12:33:00AM -0400, Tom Lane wrote: > So to default to verification would be to default to failing to > connect at all until user has created a ~/.postgresql/root.crt file with > valid, relevant entries. That seems like a nonstarter. > > It's possible that we could adopt some policy like "if the root.crt file > exists then default to verify" ... but that seems messy and unreliable, > so I'm not sure it would really add any security.
Still, it would be safer to refuse to connect until the lack of trust anchors is rectified than to connect without warning about the inability to verify a server. By forcing the user (admins) to take action to remediate the problem, the problem then gets fixed, whereas plowing on creates an invisible (for many users) security problem.
I agree with Nico. If the server certificate can't be validated, the client should fail to connect unless specifically opting out of MITM protection. Why not change DefaultSSLMode from "prefer," even if it isn't backwards compatible? Is there a policy for deprecating default settings?
