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 | [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: Sunday, October 10, 2010 3:58 PM
To: [email protected]
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 | [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
> 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 |
>> [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]
______________________________________________________________________
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]
