7.3.1 stamped

Could you put a note in HISTORY about the incompatability with pre-7.3
SSL clients?

--Nate

Nathan Mueller wrote:

Could you put a note in HISTORY about the incompatability with pre-7.3
SSL clients?

I believe that pre7-3 SSL clients will work in 7.3.1, or am I wrong?

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

I believe that pre7-3 SSL clients will work in 7.3.1, or am I wrong?

In 7.3 the SSL protocol switched from SSLv2 to TLSv1. If the server
method is switched to SSLv23_method it will be backwords compatable with
pre-7.3 clients without sacrificing the added security of TLSv1 for
newer stuff. There's been a lot of other changes to the SSL code between
7.2 and 7.3, but I've tested this out and haven't found any problems.
I've included a patch to src/backend/libpq/be-secure.c if you're
interested.

--Nate

--- be-secure.c 13 Dec 2002 18:06:44 -0000 1.3
+++ be-secure.c 18 Dec 2002 04:16:19 -0000
@@ -587,7 +587,7 @@
        {
                SSL_library_init();
                SSL_load_error_strings();
-               SSL_context = SSL_CTX_new(TLSv1_method());
+               SSL_context = SSL_CTX_new(SSLv23_method());
                if (!SSL_context)
                {
                        postmaster_error("failed to create SSL
                        context: %s",

I am confused. How can we switch back to SSLv23_method and still be
compatible with TLSv1_method. Does SSLv23_method support both?

The SSL author didn't like SSLv23_method (especially SSLv2) and I am not
confident to question his decision. We will just have to break backward
compatibility with pre-7.3 clients. No one else has mentioned it as a
problem, and in fact most have probably already upgraded to 7.3, so we
should be OK.

---------------------------------------------------------------------------

Nathan Mueller wrote:

I believe that pre7-3 SSL clients will work in 7.3.1, or am I wrong?

In 7.3 the SSL protocol switched from SSLv2 to TLSv1. If the server
method is switched to SSLv23_method it will be backwords compatable with
pre-7.3 clients without sacrificing the added security of TLSv1 for
newer stuff. There's been a lot of other changes to the SSL code between
7.2 and 7.3, but I've tested this out and haven't found any problems.
I've included a patch to src/backend/libpq/be-secure.c if you're
interested.

--Nate

--- be-secure.c 13 Dec 2002 18:06:44 -0000 1.3
+++ be-secure.c 18 Dec 2002 04:16:19 -0000
@@ -587,7 +587,7 @@
{
SSL_library_init();
SSL_load_error_strings();
-               SSL_context = SSL_CTX_new(TLSv1_method());
+               SSL_context = SSL_CTX_new(SSLv23_method());
if (!SSL_context)
{
postmaster_error("failed to create SSL
context: %s",

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

I am confused. How can we switch back to SSLv23_method and still be
compatible with TLSv1_method. Does SSLv23_method support both?

SSLv23 understands SSLv2, SSLv3 and TLSv1. When used in a client it uses
SSLv2 but tells the server it can understand the other ones too. Check
out the SSL_CTX_new manpage for a lot more details.

The SSL author didn't like SSLv23_method (especially SSLv2) and
I am not
confident to question his decision. We will just have to break
backward
compatibility with pre-7.3 clients. No one else has mentioned it as a
problem, and in fact most have probably already upgraded to 7.3, so we
should be OK.

I agree, TLSv1 is a lot better but there's no point in breaking
backwords compatibility when you don't have to. Also, given my problems
with 7.3's SSL I'd be surprised if a lot of people who use it have made
the switch.

--Nate

Nathan Mueller wrote:

I am confused. How can we switch back to SSLv23_method and still be
compatible with TLSv1_method. Does SSLv23_method support both?

SSLv23 understands SSLv2, SSLv3 and TLSv1. When used in a client it uses
SSLv2 but tells the server it can understand the other ones too. Check
out the SSL_CTX_new manpage for a lot more details.

The SSL author didn't like SSLv23_method (especially SSLv2) and
I am not
confident to question his decision. We will just have to break
backward
compatibility with pre-7.3 clients. No one else has mentioned it as a
problem, and in fact most have probably already upgraded to 7.3, so we
should be OK.

I agree, TLSv1 is a lot better but there's no point in breaking
backwords compatibility when you don't have to. Also, given my problems
with 7.3's SSL I'd be surprised if a lot of people who use it have made
the switch.

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?

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

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

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

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?

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?

It works fine for me.

--Nate

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

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

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

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.

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

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.

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

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

Bruce Momjian writes:

I have prepared the 7.3 CVS branch in preparation of a 7.3.1 release
soon. Please check it.

It would be of advantage if it were announced to the development group
ahead of time when a minor release is planned, so work can be planned
better. It is certainly extremely clumsy if the so-called release already
sits on the FTP server while some of us are stilling trying to fix things
up.

--
Peter Eisentraut peter_e@gmx.net