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
>
>> 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.