On 21 okt 2008, at 13.12, Martijn van Oosterhout <kleptog@svana.org>
wrote:
> On Tue, Oct 21, 2008 at 11:55:32AM +0100, Gregory Stark wrote:
>> Martijn van Oosterhout <kleptog@svana.org> writes:
>>
>>> You seem to be making the assertion that making an encrypted
>>> connection
>>> to an untrusted server is worse than making a plaintext connection
>>> to
>>> an untrusted server, which seems bogus to me.
>>
>> Hm, is it? If you use good old traditional telnet you know you're
>> typing on an
>> insecure connection. If you use ssh you expect it to be secure and
>> indeed ssh
>> throws up big errors if it fails to get a secure connection -- it
>> doesn't
>> silently fall back to an insecure connection.
>
> 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.
Are you referring to the method we have now? If so, it has two
problems: it's not enforceable from the app, and it's off by default.
Other than that, it works.
> 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.
Yes. The importance being that it must know which, and not just
blindly accept anything.
>
> Preventing casual snooping without preventing MitM is a rational
> choice
> for system administrators.
>
Yes, but it should not be the default. It still allows you to do this...
/mha