I'm forwarding this to the users list so that others won't be confused by the documentation as I was.
Paul -----Original Message----- From: owner-openssl-...@openssl.org [mailto:owner-openssl-...@openssl.org] On Behalf Of Paul Suhler Sent: Wednesday, October 13, 2010 11:10 AM To: openssl-...@openssl.org Subject: RE: TLS 1.1 / 1.0 Interoperation Hi, Mounir. Thanks for your help; we can now negotiate between 1.0 and 1.1. My only comment is that -- based on our testing -- only SSLv23_{server, client}_method allows negotiation. TLSv1_*_method will *not* accept TLS 1.1 connections. And SSL3_*_method will not accept TLS connections. This is actually documented in http://www.openssl.org/docs/ssl/SSL_CTX_new.html, although it doesn't (yet) mention TLS 1.1. For the benefit of whoever works on that documentation I'd recommend that it be changed to specify 1.0: TLSv1_method(void), TLSv1_server_method(void), TLSv1_client_method(void) A TLS/SSL connection established with these methods will only understand the TLSv1.0 protocol. A client will send out TLSv1.0 client hello messages and will indicate that it only understands TLSv1.0. A server will only understand TLSv1.0 client hello messages. This especially means, that it will not understand SSLv2 client hello messages which are widely used for compatibility reasons, see SSLv23_*_method(). It will also not understand SSLv3 client hello messages. And if you really want consistency, change TLSv1_method to TLSv1_0_method, etc. Unless the intention is really that TLSv1_method will accept 1.1, but that's a lot more work. Cheers, Paul ________________________________________________________________________ _____________________________ Paul A. Suhler | Firmware Engineer | Quantum Corporation | Office: 949.856.7748 | paul.suh...@quantum.com Preserving the World's Most Important Data. Yours.(tm) -----Original Message----- From: owner-openssl-...@openssl.org [mailto:owner-openssl-...@openssl.org] On Behalf Of Mounir IDRASSI Sent: Sunday, October 10, 2010 3:58 PM To: openssl-...@openssl.org Subject: Re: TLS 1.1 / 1.0 Interoperation Hi Paul, The use of an XXX_server_method function in a server defines the minimal client version it supports. SSLv23_server_method => SSLv2 SSLv3_server_method => SSLv3 TLSv1_server_method => TLS 1.0 TLSv1_1_server_method => TLS 1.1. Thus, the error you are getting is normal: you told OpenSSL to support only TLS 1.1 and that's why TLS 1.0 clients are rejected. Use TLSv1_server_method if you want to support both TLS 1.0 and TLS 1.1 clients. By the way, setting SSL_OP_NO_SSLv2 and SSL_OP_NO_SSLv3 is useless since the server only supports TLS 1.0/1.1. Cheers, -- Mounir IDRASSI IDRIX http://www.idrix.fr On 10/10/2010 6:28 AM, Paul Suhler wrote: > Hi, Mounir. > > In the server, I use TLSv1_1_server_method, resulting in s->version == > 0x0302 (TLS 1.1). In the client, I use TLSv1_client_method to get TLS > 1.0. When the server sees s->client_version == 0x0301, shouldn't it > change s->version to 0x0301 and operate thereafter in 1.0 mode? > > Thanks for the warning about the double free. > > Cheers, > > Paul > ______________________________________________________________________ > __ > _____________________________ > Paul A. Suhler | Firmware Engineer | Quantum Corporation | Office: > 949.856.7748 | paul.suh...@quantum.com Preserving the World's Most > Important Data. Yours.(tm) > > -----Original Message----- > From: owner-openssl-...@openssl.org > [mailto:owner-openssl-...@openssl.org] On Behalf Of Mounir IDRASSI > Sent: Saturday, October 09, 2010 6:37 PM > To: openssl-...@openssl.org > Subject: Re: TLS 1.1 / 1.0 Interoperation > > > Hi Paul, > > I was not able to reproduce your problem using that snapshot. I set up > an SSL server using SSLv23_server_method and set the options > SSL_OP_ALL > | SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3 as you did : I always have > s->version equal to 0x0301 as expected and the test you mentioned is > s->OK > since s->client_version is also equal to 0x0301. > Same test can be done using the command line : > openssl s_server -accept 443 -key server.pem -cert server.pem -no_ssl2 > -no_ssl3 -bugs > > Can you post a sample code that exposes the problem? > > By the way, I detected a double free in the implementation of > ssl3_send_server_key_exchange in this snapshot. I'll see if it has > been already corrected, otherwise I'll send a patch for it. > > Cheers, > -- > Mounir IDRASSI > IDRIX > http://www.idrix.fr > > On 08/10/2010 18:55, Paul Suhler wrote: >> Hi, everyone. >> >> [I'm re-sending this to the developers list.] >> >> I've found that when a server built with >> openssl-1.0.1-stable-SNAP-20101004 receives a Client Hello from a >> client specifying TLS 1.0 (version = 0x0301), the connection is >> rejected for a bad version. This appears to be implemented in >> ssl3_get_client_hello() >> by: >> >> if ((s->version == DTLS1_VERSION&& s->client_version> >> s->version) || >> (s->version != DTLS1_VERSION&& s->client_version< >> s->version)) >> { >> SSLerr(SSL_F_SSL3_GET_CLIENT_HELLO, >> SSL_R_WRONG_VERSION_NUMBER); >> >> In the SSL_CTX, I'm setting options SSL_OP_ALL | SSL_OP_NO_SSLv2 | >> SSL_OP_NO_SSLv3. I see no options that would be forcing TLS 1.1 only. >> >> However, RFC 4346 Appendix E says: >> >> Similarly, a TLS 1.1 server that wishes to interoperate with >> TLS 1.0 >> >> or SSL 3.0 clients SHOULD accept SSL 3.0 client hello messages and >> respond with a SSL 3.0 server hello if an SSL 3.0 client hello >> with a >> >> version field of {3, 0} is received, denoting that this client > does >> not support TLS. Similarly, if a SSL 3.0 or TLS 1.0 hello with a >> version field of {3, 1} is received, the server SHOULD respond >> with a >> >> TLS 1.0 hello with a version field of {3, 1}. >> >> Am I misunderstanding the requirements of the RFC, or is this part of >> the fix for the renegotiation exploit? (I'm not renegotiating when >> this happens; it's the initial connection attempt that's rejected.) >> >> Thanks very much, >> >> Paul >> _____________________________________________________________________ >> _ >> __ >> _____________________________ >> Paul A. Suhler | Firmware Engineer | Quantum Corporation | Office: >> 949.856.7748 | >> paul.suh...@quantum.com<mailto:paul.suh...@quantum.com> >> >> Preserving the World's Most Important Data. Yours.(tm) >> >> >> >> --------------------------------------------------------------------- >> - The information contained in this transmission may be confidential. > Any disclosure, copying, or further distribution of confidential > information is not permitted unless such privilege is explicitly > granted in writing by Quantum. Quantum reserves the right to have > electronic communications, including email and attachments, sent > across its networks filtered through anti virus and spam software > programs and retain such messages in order to comply with applicable > data security and retention requirements. Quantum is not responsible > for the proper and complete transmission of the substance of this > communication or for any delay in its receipt. > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > Development Mailing List openssl-...@openssl.org > Automated List Manager majord...@openssl.org > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > Development Mailing List openssl-...@openssl.org > Automated List Manager majord...@openssl.org ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-...@openssl.org Automated List Manager majord...@openssl.org ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-...@openssl.org Automated List Manager majord...@openssl.org ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
