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

I'm not an expert, but as far as I know the only real differences
between SSLv2 and v3 (which isn't different from TLSv1 from a security
standpoint) are some things to prevent some man in the middle attacks.

Thing is, most man in the middle attacks aren't that advanced. The
attacker will intercept your attempt to connect to the server, do
a handshake with you, do a handshake with the server and just sit
in between. The only way (that I know of) to defend against this
is to use certified public keys and I don't know of a way to do
that with postgres.

In short, I wouldn't call SSLv2 insecure, just less secure then v3. I
think it's perfectly reasonable to phase it out, just not right now.
It'd be nice to have some sort of transition version so you wouldn't
have to switch over all your different client programs at the same time
you switch all the servers. My preference would be for backwords
compatibility in 7.3 and then eliminate it or provide a compile time
option in 7.4. If the client stays with TLSv1 newer clients will only
use the more secure protocols and older clients will still have the same
problems they did before. I don't think that's too much of a problem.

        --Nate

Wed, 18 Dec 2002 15:04:58 -0600 (CST)
Nathan Mueller <nmueller@cs.wisc.edu>
Re: 7.3.1 stamped
On Wed, 18 Dec 2002, Nathan Mueller wrote:

> > 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.
>
> I'm not an expert, but as far as I know the only real differences
> between SSLv2 and v3 (which isn't different from TLSv1 from a security
> standpoint) are some things to prevent some man in the middle attacks.
>
> Thing is, most man in the middle attacks aren't that advanced. The
> attacker will intercept your attempt to connect to the server, do
> a handshake with you, do a handshake with the server and just sit
> in between. The only way (that I know of) to defend against this
> is to use certified public keys and I don't know of a way to do
> that with postgres.
>
> In short, I wouldn't call SSLv2 insecure, just less secure then v3. I
> think it's perfectly reasonable to phase it out, just not right now.
> It'd be nice to have some sort of transition version so you wouldn't
> have to switch over all your different client programs at the same time
> you switch all the servers. My preference would be for backwords
> compatibility in 7.3 and then eliminate it or provide a compile time
> option in 7.4. If the client stays with TLSv1 newer clients will only
> use the more secure protocols and older clients will still have the same
> problems they did before. I don't think that's too much of a problem.

Actually, would be nice if someone submit'd a patch that make choosing
which method a configure option :)

If nobody else does it, I'll try after I get back from my folks after the
holidays ...

Wed, 18 Dec 2002 22:34:07 -0400 (AST)
"Marc G. Fournier" <scrappy@hub.org>
Re: 7.3.1 stamped
Marc G. Fournier wrote:
> > In short, I wouldn't call SSLv2 insecure, just less secure then v3. I
> > think it's perfectly reasonable to phase it out, just not right now.
> > It'd be nice to have some sort of transition version so you wouldn't
> > have to switch over all your different client programs at the same time
> > you switch all the servers. My preference would be for backwords
> > compatibility in 7.3 and then eliminate it or provide a compile time
> > option in 7.4. If the client stays with TLSv1 newer clients will only
> > use the more secure protocols and older clients will still have the same
> > problems they did before. I don't think that's too much of a problem.
> 
> Actually, would be nice if someone submit'd a patch that make choosing
> which method a configure option :)
> 
> If nobody else does it, I'll try after I get back from my folks after the
> holidays ...

Well, I had time to research it and looked at that URL on SSL2
vunerabilities.  Seems all the problems are with man in the middle
cases, and with doconnections not being properly authenticated.  They
are not of the variety where you could just attach to the port and
somehow bypass a password prompt or anything like that.

If users always use TSL-capable clients, there shouldn't be any issue. 
I was kind of surprised that folks couldn't get the existing TLS code
working because I had it working here, and I don't have the newest
setup.  I though that TSL support was merely having a more recent
version of OpenSSL --- at least that's how I understood it from the SSL
author Bear.

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

Wed, 18 Dec 2002 21:37:52 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: 7.3.1 stamped
On Wed, 18 Dec 2002, Bruce Momjian wrote:

> If users always use TSL-capable clients, there shouldn't be any issue.
> I was kind of surprised that folks couldn't get the existing TLS code
> working because I had it working here, and I don't have the newest
> setup.  I though that TSL support was merely having a more recent
> version of OpenSSL --- at least that's how I understood it from the SSL
> author Bear.

Ya, but that makes an assumption that ppl clients aren't statically
compiled, and don't have the TLS option ...

Wed, 18 Dec 2002 23:21:03 -0400 (AST)
"Marc G. Fournier" <scrappy@hub.org>
Re: 7.3.1 stamped