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 scenarios depending on
whether the client user has set up the requires files in ~/.postgresql.
All this just leads users to do the wrong thing by 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.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
