Subject: [TLS] What's the right version number in the PreMasterSecret for renegotiation

From: Xuelei Fan <[email-masked]>
Date: Tue, 10 Aug 2010 10:29:31 +0800

In RFC4346/5246, the specification for client_version in the
PreMasterSecret is described as:
---------------
      struct {
          ProtocolVersion client_version;
          opaque random[46];
      } PreMasterSecret;

      client_version The latest (newest) version supported by the
         client.  This is used to detect version roll-back attacks.
         Upon receiving the premaster secret, the server SHOULD check
         that this value matches the value transmitted by the client in
         the client hello message.

      ....

   Note: The version number in the PreMasterSecret MUST be the version
         offered by the client in the ClientHello, not the version
         negotiated for the connection.  This feature is designed to
         prevent rollback attacks.
---------------

The spec is clear for initial handshaking. But while testing
renegotiation, we get two different interpretations of the version
number in the PreMasterSecret. We noticed Opera (10.50) uses the version
number offered by the renegotiation ClientHello, while Microsoft IE 8
(IE 8 at Windows 7) uses the version number offered by the ClientHello
in the initial handshaking.

For Opera, the scenario looks like:

    Opera <--------------> TLS server
         --->ClientHello V1.2--->
         <---ServerHello V1.1<---
         ...
         --->PreMasterSecret (v1.2)--->  (as expected)
         ...
         <---HelloRequest<----
         ---->ClientHello v1.1----> (ask for an abbreviated handshake)
         <---ServerHello V1.1<---   (not resumable, new session)
         ...
         --->PreMasterSecret (v1.1)---> (*)

For IE 8, the scenario looks like:

    IE 8<--------------> TLS server
         --->ClientHello V1.2--->
         <---ServerHello V1.1<---
         ...
         --->PreMasterSecret (v1.2)--->  (as expected)
         ...
         <---HelloRequest<----
         ---->ClientHello v1.1----> (ask for an abbreviated handshake)
         <---ServerHello V1.1<---   (not resumable, new session)
         ...
         --->PreMasterSecret (v1.2)---> (**)

(*) Opera uses the version number offered by the ClientHello in the
renegotiation handshaking.
(**) IE 8 uses the version number offered by the ClientHello in the
initial handshaking.

Please help to clarify what's the correct version number choice for
renegotiation.

Thanks,
Xuelei (Andrew) Fan

---

From: Michael D'Errico <[email-masked]>
Date: Mon, 09 Aug 2010 20:20:02 -0700

Based on the scenarios below, it looks like Opera is doing the right
thing during the renegotiation while IE 8 is not.

Mike

---

From: Martin Rex <[email-masked]>
Date: Tue, 10 Aug 2010 16:57:09 +0200 (MEST)

> thing during the renegotiation while IE 8 is not.

Opera is sending the correct client_version in the RSA PreMaster Secret
in both handshakes (initial and renegotiation).  Handshakes in the
originial SSLv3 and TLS protocol were completely independent and
self-contained, so the back-reference of the client_version in
RSA premaster secret is ALWAYS to the ClientHello handshake message
of the current handshake.

But both browsers should actually be sending their highest supported
protocol version as client_version on EVERY ClientHello handshake
message--independent of whether they propose session resumption--
and both browsers appear to flunk on this point.

-Martin

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: "Yngve N. Pettersen (Developer Opera Software ASA)" <[email-masked]>
Date: Tue, 10 Aug 2010 17:26:29 +0200

> and both browsers appear to flunk on this point.

I have not been able to locate the exact reason for our policy, but if we  
have an active session against a server we will use the negotiated  
protocol version in future handshakes.

This policy is 11+ years old, and was probably implemented because there  
was some kind of problem with resuming sessions using a Hello protocol  
version different from the one we used when setting up the session.

It may be possible to remove this, along with all the version fallback  
code, when we enter strict Renego patch mode.

-- 
Sincerely,
Yngve N. Pettersen

********************************************************************
Senior Developer                     Email: [email-masked]
Opera Software ASA                   http://www.opera.com/
Phone:  +47 24 16 42 60              Fax:    +47 24 16 40 01
********************************************************************

---

From: "Kyle Hamilton" <[email-masked]>
Date: Tue, 10 Aug 2010 15:35:16 -0700 (PST)

Can you please explain how and why you came to this conclusion?  (Please don't take offense, I'm not disputing the conclusion, I simply wish to be more informed as to why?)

-Kyle H

---

From: Michael D'Errico <[email-masked]>
Date: Tue, 10 Aug 2010 16:02:42 -0700

Kyle Hamilton wrote:
> Can you please explain how and why you came to this conclusion?  (Please 
> don't take offense, I'm not disputing the conclusion, I simply wish to 
> be more informed as to why?)

The problematic handshake is:

The version encoded within the PreMasterSecret is not the version
that was used in the ClientHello.  That's a violation of the spec.

The fact that the client does actually support version 1.2 is
immaterial.  A server is not expected to have logic that keeps track
of the highest version the client has ever offered in the past.

Mike

---

From: Xuelei Fan <[email-masked]>
Date: Wed, 11 Aug 2010 09:42:45 +0800

On 8/10/2010 11:26 PM, Yngve N. Pettersen (Developer Opera Software ASA)
wrote:
> I have not been able to locate the exact reason for our policy, but if
> we have an active session against a server we will use the negotiated
Java (SunJSSE) use the same policy as Opera, use the negotiated protocol
version for renegotiation.

> code, when we enter strict Renego patch mode.
I'm a little worried about the interoperability. I'm not sure, but if
some vendors care about the protocol version in renegotiation
ClientHello, for example, comparing the ClientHello.client_version with
the cached negotiated protocol version.

Anyone know which TLS implementations do not use the negotiated protocol
version for abbreviated handshake?

Thanks,
Xuelei (Andrew) Fan

---

From: Martin Rex <[email-masked]>
Date: Wed, 11 Aug 2010 10:38:49 +0200 (MEST)

Xuelei Fan wrote:
> 
> Yngve N. Pettersen (Developer Opera Software ASA) wrote:
> > Martin Rex <[email-masked]> wrote:
> > >

Technically, this should be just fine.

> the cached negotiated protocol version.

You are probably right, sending the protocol version from the
session that is proposed for resume is the more conservative approach,
with a lesser likelihood to tickle bugs.

IF the server agrees to session resumption, then the session MUST be
resumed with the original protocol version.  It would be bug in the
server if it would resume the session with a different protocol
version, and it would be a bug in the client to agree to resuming
the session with a different protocol version.

AFAIK, the architecture behind TLS session caching is that it is
resumed "as is" from the session cache, with all characteristics as
established in the full handshake that created this session
that includes protocol version, cipher suite, compression alg,
active TLS extensions.

Doing otherwise might have unexpected side effects.  A TLS session
resumption omits the exchange of certificate messages and therefore
might omit some checks that were (for whatever reason) tied into
the certificate path validation.

> version for abbreviated handshake?

Anyone know which TLS client would agree to resuming with a different
protocol version if a buggy server would do this based on the
ClientHello.client_version differing from the protocol version of
the cached session that is proposed for resumption?

-Martin