Re: version 2 is used for Client Hello when version 3 was requested in client code

2005-05-12 Thread Bodo Moeller 
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_ALL

 | SSL_OP_NO_SSLv2); to disable SSLv2 support.

 Is it normal that the Client Hello message is SSLv2 and later TLS is
 used?

 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   openssl-dev@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: version 2 is used for Client Hello when version 3 was requested in client code

2005-05-12 Thread Thomas 
  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.)

[...]

Thanks for the answer! :)

Thomas

-- 
Tom [EMAIL PROTECTED]
fingerprint = F055 43E5 1F3C 4F4F 9182  CD59 DBC6 111A 8516 8DBF
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   [EMAIL PROTECTED]

version 2 is used for Client Hello when version 3 was requested in client code

2005-05-11 Thread Thomas Biege 
Hi,
well the (too long) subject explains it very well.

But here are the details.

I used the code from the book Network Security with OpenSSL to play
around with SSL.

The client code looks like:
SSL_CTX *setup_client_ctx(void)
{
SSL_CTX *ctx;

ctx = SSL_CTX_new(SSLv23_method());

if(SSL_CTX_load_verify_locations(ctx, CAFILE, CADIR) != 1)
int_error(Error loading CA file and/or directory.);
if(SSL_CTX_set_default_verify_paths(ctx) != 1)
int_error(Error loading default CA file and/or directory.);

SSL_CTX_set_verify(ctx, SSL_VERIFY_PEER, verify_callback);
SSL_CTX_set_verify_depth(ctx, 4);

SSL_CTX_set_options(ctx, SSL_OP_ALL|SSL_OP_NO_SSLv2);

if(SSL_CTX_set_cipher_list(ctx, CIPHER_LIST) != 1)
int_error(Error setting cipher list (no valid ciphers));

return ctx;
}

You see I use SSLv23_method() and later SSL_CTX_set_options(ctx, SSL_OP_ALL
| SSL_OP_NO_SSLv2); to disable SSLv2 support.

Is it normal that the Client Hello message is SSLv2 and later TLS is used?

If I use SSLv3_method() everything works as expected.

I attached a ethereal capture file (see frame 4). Maybe the ethereal decoder
makes a mistake here or maybe it is normal behaviour.

Thanks,
Thomas

-- 
TheTom [EMAIL PROTECTED]
fingerprint = F055 43E5 1F3C 4F4F 9182  CD59 DBC6 111A 8516 8DBF


sslv2.bin
Description: Binary data


pgpEM7nvEdv1Q.pgp
Description: PGP signature