> Well, we break backward compatibility so people can't use SSL2 to
> connect to the server. Backward compatibility to a broken protocol
> isn't what I would call secure. Is that accurate?

I suppose. As long as the incompatibilty is mentioned in HISTORY I'm
fine.

        --Nate

Tue, 17 Dec 2002 22:48:40 -0600 (CST)
Nathan Mueller <nmueller@cs.wisc.edu>
Re: 7.3.1 stamped
Nathan Mueller wrote:
> > Well, we break backward compatibility so people can't use SSL2 to
> > connect to the server. Backward compatibility to a broken protocol
> > isn't what I would call secure. Is that accurate?
> 
> I suppose. As long as the incompatibilty is mentioned in HISTORY I'm
> fine.

Uh, I didn't get it in there because we were still discussing it while I
was packaging 7.3.1.  Sorry.  I can mention it in 7.3.2. 

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

Tue, 17 Dec 2002 23:50:09 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: 7.3.1 stamped
On Tue, 17 Dec 2002, Nathan Mueller wrote:

> > Well, we break backward compatibility so people can't use SSL2 to
> > connect to the server. Backward compatibility to a broken protocol
> > isn't what I would call secure. Is that accurate?
>
> I suppose. As long as the incompatibilty is mentioned in HISTORY I'm
> fine.

I read the SSL_CTX_new man page, and they recommend using SSLv23_method to
provide backwards compatibility ... if someone doesn't wan tto use SSL2,
they have the option to use TLS, but we shouldn't be forcigin them to use
one or the othe r...

I have made the change and am just building v7.3.1 right now ... should be
available in a few minutes, and I'll announce it this evening as being
available ... can you grab a copy and make sure that it works as expected?

Wed, 18 Dec 2002 09:37:15 -0400 (AST)
"Marc G. Fournier" <scrappy@hub.org>
Re: 7.3.1 stamped
Marc G. Fournier wrote:
> On Tue, 17 Dec 2002, Nathan Mueller wrote:
> 
> > > Well, we break backward compatibility so people can't use SSL2 to
> > > connect to the server. Backward compatibility to a broken protocol
> > > isn't what I would call secure. Is that accurate?
> >
> > I suppose. As long as the incompatibilty is mentioned in HISTORY I'm
> > fine.
> 
> I read the SSL_CTX_new man page, and they recommend using SSLv23_method to
> provide backwards compatibility ... if someone doesn't wan tto use SSL2,
> they have the option to use TLS, but we shouldn't be forcigin them to use
> one or the othe r...
> 
> I have made the change and am just building v7.3.1 right now ... should be
> available in a few minutes, and I'll announce it this evening as being
> available ... can you grab a copy and make sure that it works as expected?

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.

-- 
  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 14:43:09 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: 7.3.1 stamped
On Wed, 18 Dec 2002, Bruce Momjian wrote:

> Marc G. Fournier wrote:
> > On Tue, 17 Dec 2002, Nathan Mueller wrote:
> >
> > > > Well, we break backward compatibility so people can't use SSL2 to
> > > > connect to the server. Backward compatibility to a broken protocol
> > > > isn't what I would call secure. Is that accurate?
> > >
> > > I suppose. As long as the incompatibilty is mentioned in HISTORY I'm
> > > fine.
> >
> > I read the SSL_CTX_new man page, and they recommend using SSLv23_method to
> > provide backwards compatibility ... if someone doesn't wan tto use SSL2,
> > they have the option to use TLS, but we shouldn't be forcigin them to use
> > one or the othe r...
> >
> > I have made the change and am just building v7.3.1 right now ... should be
> > available in a few minutes, and I'll announce it this evening as being
> > available ... can you grab a copy and make sure that it works as expected?
>
> 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??


Wed, 18 Dec 2002 15:55:21 -0400 (AST)
"Marc G. Fournier" <scrappy@hub.org>
Re: 7.3.1 stamped
Marc G. Fournier wrote:
> > 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??

I wasn't sure how insecure SSL2 was, and whether it allowed you to
authenticate without a password or something.

-- 
  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 14:58:20 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: 7.3.1 stamped
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.


Wed, 18 Dec 2002 13:23:05 -0700 (MST)
"scott.marlowe" <scott.marlowe@ihs.com>
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@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 15:30:36 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: 7.3.1 stamped
On Wed, 18 Dec 2002, Bruce Momjian wrote:

> Marc G. Fournier wrote:
> > > 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??
> 
> I wasn't sure how insecure SSL2 was, and whether it allowed you to
> authenticate without a password or something.

SSL2 seems to get a lot of votes for being broken in ways that cannot be 
fixed because they aren't simple buffer overflows.  see:

http://www.lne.com/ericm/papers/ssl_servers.html#1.2

My suggestion would be to eventually phase out ssl2 in favor of ssl3 or 
tls.  And, as we are phasing it out, make it an opt-in thing, where the 
dba has to turn on ssl2 KNOWING he is turning on a flawed protocol.


Wed, 18 Dec 2002 13:46:14 -0700 (MST)
"scott.marlowe" <scott.marlowe@ihs.com>
Re: 7.3.1 stamped
scott.marlowe wrote:
> > I wasn't sure how insecure SSL2 was, and whether it allowed you to
> > authenticate without a password or something.
> 
> SSL2 seems to get a lot of votes for being broken in ways that cannot be 
> fixed because they aren't simple buffer overflows.  see:
> 
> http://www.lne.com/ericm/papers/ssl_servers.html#1.2
> 
> My suggestion would be to eventually phase out ssl2 in favor of ssl3 or 
> tls.  And, as we are phasing it out, make it an opt-in thing, where the 
> dba has to turn on ssl2 KNOWING he is turning on a flawed protocol.

That was sort of my point --- if we allow SSLv2 in the server, are we
open to any security problems?  Maybe not.  I just don't know.

-- 
  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 16:28:13 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: 7.3.1 stamped
On Wed, 18 Dec 2002, Bruce Momjian wrote:

> scott.marlowe wrote:
> > > I wasn't sure how insecure SSL2 was, and whether it allowed you to
> > > authenticate without a password or something.
> >
> > SSL2 seems to get a lot of votes for being broken in ways that cannot be
> > fixed because they aren't simple buffer overflows.  see:
> >
> > http://www.lne.com/ericm/papers/ssl_servers.html#1.2
> >
> > My suggestion would be to eventually phase out ssl2 in favor of ssl3 or
> > tls.  And, as we are phasing it out, make it an opt-in thing, where the
> > dba has to turn on ssl2 KNOWING he is turning on a flawed protocol.
>
> That was sort of my point --- if we allow SSLv2 in the server, are we
> open to any security problems?  Maybe not.  I just don't know.

My understanding of SSL/TLS is that the DBA himself has to enable it ...
there has to be a server/client key setup, similar to how it gets done
with Apache for https connections ... can someone confirm whether this is
the case?

Wed, 18 Dec 2002 22:30:18 -0400 (AST)
"Marc G. Fournier" <scrappy@hub.org>
SSL/TLS support (Was: Re: 7.3.1 stamped)
Marc G. Fournier wrote:
> > > My suggestion would be to eventually phase out ssl2 in favor of ssl3 or
> > > tls.  And, as we are phasing it out, make it an opt-in thing, where the
> > > dba has to turn on ssl2 KNOWING he is turning on a flawed protocol.
> >
> > That was sort of my point --- if we allow SSLv2 in the server, are we
> > open to any security problems?  Maybe not.  I just don't know.
> 
> My understanding of SSL/TLS is that the DBA himself has to enable it ...
> there has to be a server/client key setup, similar to how it gets done
> with Apache for https connections ... can someone confirm whether this is
> the case?

Uh, I just followed the steps in the PostgresSQL install instructions:
	
	openssl req -new -text -out server.req
	openssl rsa -in privkey.pem -out server.key
	rm privkey.pem
	openssl req -x509 -in server.req -text -key server.key -out server.crt
	chmod og-rwx server.key

Isn't that similar to what was required in 7.2.X?

-- 
  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:34:34 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: SSL/TLS support (Was: Re: 7.3.1 stamped)
Bruce Momjian wrote:
> Marc G. Fournier wrote:
> 
>>>>My suggestion would be to eventually phase out ssl2 in favor of ssl3 or
>>>>tls.  And, as we are phasing it out, make it an opt-in thing, where the
>>>>dba has to turn on ssl2 KNOWING he is turning on a flawed protocol.
>>>
>>>That was sort of my point --- if we allow SSLv2 in the server, are we
>>>open to any security problems?  Maybe not.  I just don't know.

There are some weaknesses in SSLv2 that were fixed in SSLv3, but 
it takes a knowledgeable attacker to exploit them.  Anyone who is 
seriously concerned can easily change the startup code in both 
client and server and migrate to TLSv1.  We kept the current 
approach solely for backward compatibilty.

Bear


Sat, 28 Dec 2002 14:15:48 -0700
Bear Giles <bgiles@coyotesong.com>
Re: SSL/TLS support (Was: Re: 7.3.1 stamped)