On 21 okt 2008, at 13.12, Martijn van Oosterhout <[EMAIL PROTECTED]>
wrote:
On Tue, Oct 21, 2008 at 11:55:32AM +0100, Gregory Stark wrote:
Martijn van Oosterhout <[EMAIL PROTECTED]> 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
