On 21 okt 2008, at 13.41, Peter Eisentraut <peter_e@gmx.net> 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