Re: SSL cleanups/hostname verification

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