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 a
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 me
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 progr
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 a
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 defina
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
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 cl
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
> 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,
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
> > > sup
> > 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
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 establishe
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 wa
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 cal
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
> 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
---(
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
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.
> 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:
> > 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 one
> 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
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
> 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
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
[EMAIL PROTECTED] | (610) 359-1
Could you put a note in HISTORY about the incompatability with pre-7.3
SSL clients?
--Nate
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PR
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
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your b
26 matches
Mail list logo
