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 | 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-dev@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-dev@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-dev@openssl.org
Automated List Manager majord...@openssl.org
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
