Re: 7.3.1 stamped

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

At this point, all the SSL2 problems are conjecture on my part, which I
don't understand. I hesitate to do anything until someone really
knowledgeable can comment. Re-enabling SSL2 as part of 7.3.1 makes
sense until we can get a definative answer on the risks involved.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073