Support for TLS 1.1
Imported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=3755
Reported by @grubba
From: "Yngve N. Pettersen (Developer Opera Software ASA)" <yngve@opera.com>
Organization: Opera Software AS
To: "grubba@roxen.com" <grubba@roxen.com>,
"nilsson@roxen.com" <nilsson@roxen.com>, "bill@roxen.com"
<bill@roxen.com>
Cc: Yngve N. Pettersen <yngve@opera.com>, Developer Opera Software ASA:
Date: Sun, 04 Jul 2004 19:35:57 +0200
Subject: Roxen/Pike is not TLS (Transport Layer Security) forward
compatible with TLS 1.1
Hi,
I noticed your names in recent updates of the file "handshake.pike" file of the Roxen/Pike CVS repository, and I am sending this email directly to you as I assume you would be the ones to handle this report anyway. Just in case I'm writing this in English.
I am a developer with Opera Software ASA, and one of my work areas is the Opera browser's SSL/TLS protocol support.
I've recently been testing Opera's new TLS 1.1 implementation (presently an IETF draft status document) and have unfortunately found that the Roxen/Pike server is not (at least according to my understanding) properly implementing RFC 2246.
The result is that no TLS 1.1 capable client is able to connect to a Roxen/Pike TLS server, unless TLS 1.1 is disabled.
If I read the source at http://community.roxen.com/_internal/cvsview!0/94970/1.49/1/handshake.pike correctly, any version number higher than 3.1 (TLS 1.0) will result in a closed connection.
RFC 2246 (and the SSL v3 specification before it) clearly states (RFC 2246 sec. 7.4.1.2 and 7.4.1.3):
client_version
The version of the TLS protocol by which the client wishes to
communicate during this session. This should be the latest
(highest valued) version supported by the client. For this
version of the specification, the version will be 3.1
server_version
This field will contain the lower of that suggested by the client
in the client hello and the highest supported by the server. For
this version of the specification, the version is 3.1
Similar language exists in the TLS 1.1 draft, except the version number is 3.2.
This means that a client even if the client sends version 3.0 the server should respond with 3.0, but it also imply that if the client sends version 3.2 the server should send 3.1 (if TLS 1.0 is the highest version supported).
According to my reading, Roxen/Pike does not do this at present, it just terminates the connection.
What your code should do is to keep the version number sent by the client in a separate version number storage, as it is needed to validate the RSA encrypted premaster secret message block (RFC 2246 sec 7.4.7.1), and then set the actual version number to be used to the lowest version number of the higest supported by the client and the highest supported by the server. In your case that means falling back to TLS 1.0.
IMO you should fix this problem as soon as possible. I expect that TLS 1.1 will become an RFC within 3-12 months (just my opinion, something might delay it), and Opera will most likely start shipping final versions with TLS 1.1 shortly afterwards. AFAIK there are at least two TLS 1.1 capable software libraries available: GnuTLS and cryptolib.
References:
TLS 1.0: http://www.ietf.org/rfc/rfc2246.txt TLS 1.1 draft: http://www.ietf.org/internet-drafts/draft-ietf-tls-rfc2246-bis-06.txt
-- Sincerely, Yngve N. Pettersen
Senior Developer Email: yngve@opera.com Opera Software ASA http://www.opera.com/ Phone: +47 24 16 42 60 Fax: +47 24 16 40 01