Re: 7.3.1 stamped - Mailing list pgsql-hackers

On Wed, 18 Dec 2002, Marc G. Fournier wrote:

> On Wed, 18 Dec 2002, Bruce Momjian wrote:
> 
> > OK, I see from your commit message:
> >
> >  From the SSL_CTX_new man page:
> >
> >  "SSLv23_method(void), SSLv23_server_method(void), SSLv23_client_method(void)
> >
> >  A TLS/SSL connection established with these methods will understand the SSLv2,
> >  SSLv3, and TLSv1 protocol. A client will send out SSLv2 client hello messages
> >  and will indicate that it also understands SSLv3 and TLSv1. A server will
> >  understand SSLv2, SSLv3, and TLSv1 client hello messages. This is the best
> >  choice when compatibility is a concern."
> >
> >  This will maintain backwards compatibility for those us that don't use
> >  TLS connections ...
> >
> > My question is whether it is safe to be making this change in a minor
> > release?  Does it work with 7.3 to 7.3.1 combinations?  My other
> > question is, if SSLv2 isn't secure, couldn't a client say they only
> > support SSLv2, and hence break into the server?  That was my original
> > hesitancy, that and the fact Bear the SSL guy didn't want it.
> 
> Wow, which part of "A TLS/SSL connection established with these methods
> will understand the SSLv2, SSLv3, and TLSv1 protocol" are you finiding
> particularly confusing?  As nate explained to you, and the man page
> section I commited states, TLSv1_method *only* supports TLS connections
> ... SSLv23_method supports SSLv2, v3 and TLSv1 ...
> 
> As for 'break into the server" ... ummm ... isn't that what pg_hba.conf is
> for?  I don't know about servers you run, but I don't let just anyone
> connect to my server, and, in fact, close down the databases themsleves to
> specific users ... if you don't trust the client, why are you giving him
> accss to your data, regardless of the protocol being used to encrypt the
> sessino??

But, insecure SSL allows for "man in the middle" type of attacks.  I.e. 
someone can sniff your secure (?) connection and get the password out of 
it, then spoof your IP and get in.  The REASON for including TLS/SSL was 
to give people the ability to connect in a secure method so that IF 
someone is trying to listen in, they can't grab your name/password or 
your data.  

Allowing SSL connects means that that could happen.  Disallowing them 
inconveniences the user.  My suggestion would be to implement another GUC 
that by default turns off the insecure connections, and has to be 
uncommented and changed by the dba to allow the server to serve the 
insecure SSL method.  Best of both worlds.