On 21 okt 2008, at 13.41, Peter Eisentraut <[EMAIL PROTECTED]> wrote:
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.
Yes, see the discussion with Dan Kaminsky on list a while back, which
is what prompted me to finally getting around to fixing this long-time
todo...
/mha
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
