Thread: 7.3.1 stamped
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
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, Pennsylvania19073
> 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,
Pennsylvania19073
> 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, Pennsylvania19073
> 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, Pennsylvania19073
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 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
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, Pennsylvania19073
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, Pennsylvania19073
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, Pennsylvania19073
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
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?
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 ...
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
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
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 ...
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