This is a discussion on Re: version 2 is used for "Client Hello" when version 3 was requested in client code - Openssl ; On Thu, May 12, 2005 at 09:40:38AM +0200, Thomas wrote: > Am Freitag, 13. Mai 2005 20:32 schrieb Bodo Moeller: > > On Wed, May 11, 2005 at 02:14:23PM +0200, Thomas Biege wrote: >>> You see I use SSLv23_method() and ...
On Thu, May 12, 2005 at 09:40:38AM +0200, Thomas wrote:
> Am Freitag, 13. Mai 2005 20:32 schrieb Bodo Moeller:
> > On Wed, May 11, 2005 at 02:14:23PM +0200, Thomas Biege wrote:
>>> You see I use SSLv23_method() and later SSL_CTX_set_options(ctx,
>>> | SSL_OP_NO_SSLv2); to disable SSLv2 support.
>>> Is it normal that the "Client Hello" message is SSLv2 and later TLS is
>> Yes. In the past this used to be necessary because some SSL 3.0
>> implementations were confused by seeing TLS 1.0 records in the Client
>> Hello. But now these issues should be history.
> Why wasn't SSLv3(.0) be used? Or will only headers of SSLv3(.1) be
> identified as "real" SSLv3? I am confused a bit b/c everyone tells you that
> SSLv2 isn't secure and so usage of it should be avoided... and then it was
> used silently. Maybe its insecurity doesn't matter in this early stage.
With SSL_OP_NO_SSLv2, SSL 2.0 was never used, so its security problems
did not apply. The SSL 2.0 compatible client hello message that was
generated by SSLv23_client_method() is just a different way of
arranging essentially the same information that occurs in an SSL 3.0
or TLS 1.0 client hello message. (You just can't list compression
techniques in the SSL 2.0 format, and you can't include TLS
extensions. TLS extensions are not yet supported by OpenSSL, though.)
When the SSL 2.0 compatible client hello is *not* used, the data sent
by the client contains two version numbers: One is the version number
in the record headers (the SSL 2.0 format does not have anything like
this); the second is the version number given in the actual client
hello message (the maximum protocol version supported by the client).
In the past when many servers supported only SSL 2.0 and 3.0 but not
TLS 1.0, setting the version number in the record header to 3.1 (for
TLS 1.0) could lead to some servers rejecting such packets because,
not recognizing the record header format, they did not even look at
the actual client hello message -- clients had to use the SSL 2.0
format to avoid this server bug. By now, this is no longer a problem,
and even when clients use a nonsense version number such as 3.42,
servers will simply reply with the maximum protocol version that they
support (i.e., either TLS 1.0 or SSL 3.0).
OpenSSL Project http://www.openssl.org
Development Mailing List firstname.lastname@example.org
Automated List Manager email@example.com