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 | [email protected] Preserving the World's Most Important Data. Yours.(tm) -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Mounir IDRASSI Sent: Saturday, October 09, 2010 6:37 PM To: [email protected] 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 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 | [email protected]<mailto:[email protected]> > > 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 [email protected] Automated List Manager [email protected] ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [email protected]
