Thread: 7.3.1 stamped

7.3.1 stamped

From
Bruce Momjian
Date:
I have prepared the 7.3 CVS branch in preparation of a 7.3.1 release
soon.  Please check 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,
Pennsylvania19073
 


Re: 7.3.1 stamped

From
Nathan Mueller
Date:
Could you put a note in HISTORY about the incompatability with pre-7.3
SSL clients?
       --Nate


Re: 7.3.1 stamped

From
Bruce Momjian
Date:
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,
Pennsylvania19073
 


Re: 7.3.1 stamped

From
Nathan Mueller
Date:
> 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",
 


Re: 7.3.1 stamped

From
Bruce Momjian
Date:
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,
Pennsylvania19073
 


Re: 7.3.1 stamped

From
Nathan Mueller
Date:
> 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


Re: 7.3.1 stamped

From
Bruce Momjian
Date:
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,
Pennsylvania19073
 


Re: 7.3.1 stamped

From
Nathan Mueller
Date:
> 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


Re: 7.3.1 stamped

From
Bruce Momjian
Date:
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,
Pennsylvania19073
 


Re: 7.3.1 stamped

From
"Marc G. Fournier"
Date:
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?


Re: 7.3.1 stamped

From
Nathan Mueller
Date:
> 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


Re: 7.3.1 stamped

From
Bruce Momjian
Date:
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
sendout SSLv2 client hello messagesand will indicate that it also understands SSLv3 and TLSv1. A server willunderstand
SSLv2,SSLv3, and TLSv1 client hello messages. This is the bestchoice when compatibility is a concern."
 
This will maintain backwards compatibility for those us that don't useTLS 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,
Pennsylvania19073
 


Re: 7.3.1 stamped

From
"Marc G. Fournier"
Date:
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??



Re: 7.3.1 stamped

From
Bruce Momjian
Date:
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,
Pennsylvania19073
 


Re: 7.3.1 stamped

From
"scott.marlowe"
Date:
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.



Re: 7.3.1 stamped

From
Bruce Momjian
Date:
> > 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,
Pennsylvania19073
 


Re: 7.3.1 stamped

From
"scott.marlowe"
Date:
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.



Re: 7.3.1 stamped

From
Nathan Mueller
Date:
> 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


Re: 7.3.1 stamped

From
Bruce Momjian
Date:
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,
Pennsylvania19073
 


Re: 7.3.1 stamped

From
Peter Eisentraut
Date:
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



SSL/TLS support (Was: Re: 7.3.1 stamped)

From
"Marc G. Fournier"
Date:
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?


Re: 7.3.1 stamped

From
"Marc G. Fournier"
Date:
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 ...


Re: SSL/TLS support (Was: Re: 7.3.1 stamped)

From
Bruce Momjian
Date:
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.reqopenssl rsa
-inprivkey.pem -out server.keyrm privkey.pemopenssl req -x509 -in server.req -text -key server.key -out server.crtchmod
og-rwxserver.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,
Pennsylvania19073
 


Re: 7.3.1 stamped

From
Bruce Momjian
Date:
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,
Pennsylvania19073
 


Re: 7.3.1 stamped

From
"Marc G. Fournier"
Date:
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 ...


Re: SSL/TLS support (Was: Re: 7.3.1 stamped)

From
Bear Giles
Date:
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