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.
