Re: Direct SSL connection with ALPN and HBA rules
От | Jelte Fennema-Nio |
---|---|
Тема | Re: Direct SSL connection with ALPN and HBA rules |
Дата | |
Msg-id | CAGECzQT8r3OGck0vOxPqhBK-SHba1fCwrFGOT3JBFHs=uPeZfA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Direct SSL connection with ALPN and HBA rules (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Direct SSL connection with ALPN and HBA rules
|
Список | pgsql-hackers |
On Mon, 13 May 2024 at 18:14, Robert Haas <robertmhaas@gmail.com> wrote: > I disagree with Jacob's assertion that sslmode=require has no security > benefits over sslmode=prefer. That seems like the kind of pessimism > that makes people hate security professionals. There have got to be > some attacks that are foreclosed by encrypting the connection, even if > you don't stop MITM attacks or other things that are more > sophisticated than running wireshark and seeing what goes by on the > wire. 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).
В списке pgsql-hackers по дате отправления: