On Tue, Oct 21, 2008 at 08:47:35AM -0400, Tom Lane wrote: > Um, IIRC what it's checking there is the server's key signature, which > has nada to do with certificates.
That depends on whether you used an X.509 certificate to authenticate the original signature. Just about nobody does, but AIUI, there's a way to do so. Anyway, in the strict sense you're right, but the comparison is wrong anyway. SSH doesn't pretend to be authenticating over SSL. It's authenticating using the SSH protocol, which has its own RFCs describing it. If I understand the description of the current behaviour, I have to agree with those who say the current behaviour is almost worse than nothing. In the presence of DNS forgery (and I'll bet a pretty good lunch most people aren't using DNSSEC), it's not hard to send a client to the wrong server. If the ssl-using client will blithely proceed if it can't authenticate the server, it's pretty hard to see in what sense this is a conforming use of anything I know as SSL. SSL is supposed to provide both encryption and authentication (the self-signed certificate nonsense is actually breakage that everyone in the protocol community wails about whenever given the opportunity, because of the results in user behaviour. It was a compromise that people made back in the period when Verisign had a lock on the market and would charge you an arm and a leg for a cert). A [Actually, to be pedantic, it might be better to call the authentication method TLS, so as not to conflate it with the Netscape-defined SSL. But this is maybe straying into a different topic.] -- Andrew Sullivan [EMAIL PROTECTED] +1 503 667 4564 x104 http://www.commandprompt.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers