On Mon, May 13, 2024 at 1:42 PM Jelte Fennema-Nio <postg...@jeltef.nl> wrote: > Like Jacob already said, I guess you meant me here. The main point I > was trying to make is that sslmode=require is extremely insecure too, > so if we're changing the default then I'd rather bite the bullet and > actually make the default a secure one this time. No-ones browser > trusts self-signed certs by default, but currently lots of people > trust self-signed certs when connecting to their production database > without realizing. > > IMHO the only benefit that sslmode=require brings over sslmode=prefer > is detecting incorrectly configured servers i.e. servers that are > supposed to support ssl but somehow don't due to a misconfigured > GUC/pg_hba. Such "incorrectly configured server" detection avoids > sending data to such a server, which an eavesdropper on the network > could see. Which is definitely a security benefit, but it's an > extremely small one. In all other cases sslmode=prefer brings exactly > the same protection as sslmode=require, because sslmode=prefer > encrypts the connection unless postgres actively tells the client to > downgrade to plaintext (which never happens when the server is > configured correctly).
I think I agree with *nearly* every word of this. However: (1) I don't want to hijack this thread about a v17 open item to talk too much about a hypothetical v18 proposal. (2) While in general you need more than just SSL to ensure security, I'm not sure that there's only one way to do it, and I doubt that we should try to pick a winner. (3) I suspect that even going as far as sslmode=require by default is going to be extremely painful for hackers, the project, and users. Moving the goalposts further increases the likelihood of nothing happening at all. -- Robert Haas EDB: http://www.enterprisedb.com