Re: SSL cleanups/hostname verification
От | Peter Eisentraut |
---|---|
Тема | Re: SSL cleanups/hostname verification |
Дата | |
Msg-id | 48FDBFD7.6000208@gmx.net обсуждение исходный текст |
Ответ на | Re: SSL cleanups/hostname verification (Martijn van Oosterhout <kleptog@svana.org>) |
Ответы |
Re: SSL cleanups/hostname verification
(Magnus Hagander <magnus@hagander.net>)
Re: SSL cleanups/hostname verification (Magnus Hagander <magnus@hagander.net>) Re: SSL cleanups/hostname verification (Martijn van Oosterhout <kleptog@svana.org>) |
Список | pgsql-hackers |
Martijn van Oosterhout wrote: > SSH is a good example, it only works with self-signed certificates, and > relies on the client to check it. Libpq provides a mechanism for the > client to verify the server's certificate, and that is safe even if it > is self-signed. > > If the client knows the certificate the server is supposed to present, > then you can't have a man-in-the-middle attack, right? Whether it's > self-signed or not is irrelevent. That appears to be correct, but that was not the original issue under discussion. Both a web browser and an SSH client will, when faced with an untrusted certificate, pop a question to the user. The user then verifies the certificate some other way (in theory), answers/clicks yes, and then web browser and SSH client store the certificate locally marked as trusted, so this question goes away the next time. An SSL-enabled libpq program will, when faced with an untrusted certificate, go ahead anyway, without notification. (Roughly speaking. If I understand this right, there are other scenariosdepending on whether the client user has set up the requires files in ~/.postgresql. All this just leads users to do the wrong thingby neglect, ignorance, or error.) The change Magnus proposes is that SSL-enabled libpq programs will in the future refuse to connect without a trusted certificate. Being a library, we cannot really go ask the user, as web browser and SSH client do, but I could imagine that we could make psql do that and store the trusted certificate automatically in a local place. Then we would be close to the usual operating mode for SSH and web browsers, and then chances are better that users can understand this setup and use it securely and easily. > Preventing casual snooping without preventing MitM is a rational choice > for system administrators. I am not an expert in these things, but it seems to me that someone who can casually snoop can also casually insert DHCP or DNS packages and redirect traffic. There is probably a small niche where just encryption without server authentication prevents information leaks, but it is not clear to me where this niche is or how it can be defined, and I personally wouldn't encourage this sort of setup.
В списке pgsql-hackers по дате отправления: