TLS 1.1 / 1.0 Interoperation

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

TLS 1.1 / 1.0 Interoperation

Paul Suhler
TLS 1.1 / 1.0 Interoperation

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 | [hidden email] 
Preserving the World's Most Important Data. Yours.™  

 


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.
Reply | Threaded
Open this post in threaded view
|

Re: TLS 1.1 / 1.0 Interoperation

Mounir IDRASSI
  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 | [hidden email]<mailto:[hidden email]>
>
> 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                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: TLS 1.1 / 1.0 Interoperation

Paul Suhler
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 | [hidden email]  
Preserving the World's Most Important Data. Yours.(tm)

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Mounir IDRASSI
Sent: Saturday, October 09, 2010 6:37 PM
To: [hidden email]
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 | [hidden email]<mailto:[hidden email]>
>
> 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                       [hidden email]
Automated List Manager                           [hidden email]
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: TLS 1.1 / 1.0 Interoperation

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

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: TLS 1.1 / 1.0 Interoperation

Paul Suhler
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 | [hidden email]  
Preserving the World's Most Important Data. Yours.(tm)

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

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: TLS 1.1 / 1.0 Interoperation

Mounir IDRASSI
  Hi Paul,

I'm glad to see that my post helped you even if it was not completely
correct.
I answered too quickly and I wrongly extrapolated the
SSLv23_server_method behavior to the others.

Cheers,
--
Mounir IDRASSI
IDRIX
http://www.idrix.fr

On 10/13/2010 8:10 PM, Paul Suhler wrote:

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

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]