Subject: [TLS] TLS versions when renegotiating...

From: Dr Stephen Henson <[email-masked]>
Date: Thu, 09 Feb 2012 16:13:48 +0000

While performing interop testing with some servers an issue arose relating to
renegotiation and TLS clients supporting TLS 1.1 or later and servers only
supporting 1.0.

One scenario is this:

1. Client connects using compatible client hello indicating maximum version
   of TLS 1.2.
2. Server only supports TLS 1.0 so sends back server hello containing version
   1.0. RSA key exchange ciphersuite indicated.
3. Connection proceeds using TLS 1.0 with client using maximum supported
   version of 1.2 in RSA encrypted premaster secret.

All fine so far. Now suppose the connection renegotiates (e.g. we requested a
URL needing client authentication). It might go like this...

4. Server sends hello request requesting renegotiation.
5. Client sends client hello containing version 1.0 this time as we know that
   is all the server supports.
6. Connection proceeds using TLS v1.0.

Question is: what version should go in the RSA encrypted premaster secret?

Possible answers:

a. Same value as in the corresponding client hello for that handshake as that
   is the maximum version we will permit i.e. 1.0.
b. Be consistent with initial client hello and use 1.2 as that is the maximum
   version we support.

The problem is whichever one you choose some widely deployed servers will choke
on it.

The servers which choke on (a) work fine if RSA key exchange is not used but
they seem to prioritise RSA key exhchange ciphersuites even if others have
precedence in the client hello.

My current workaround is to avoid the client hello with version 1.0 when
renegotiating and use a compatible client hello using version 1.2 and keeping
that in the RSA encrypted premaster secret.

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: [email-masked], PGP key: via homepage.

---

From: Yoav Nir <[email-masked]>
Date: Thu, 9 Feb 2012 18:27:28 +0200

Hi.

I don't think that any sane reading of RFC 5246 (or 2246) can lead us to any conclusion other than a.

Personally, I think the solution for the server is to accept in the ClientKeyExchange all version numbers at least equal to its highest supported version. So in that example, we would accept 3.1, 3.2, 3.3, or even 3.99, but not 3.0.

Downgrade attacks are still thwarted (although the hash in the Finished message does that as well), but upgrade attacks are not. Are we worried about upgrade attacks?  I think not.

Yoav

On Feb 9, 2012, at 6:13 PM, Dr Stephen Henson wrote:

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
> 
> Scanned by Check Point Total Security Gateway.

---

From: Martin Rex <[email-masked]>
Date: Sat, 11 Feb 2012 06:33:38 +0100 (MET)

Just follow the spec:

   7.4.1.2  Client Hello

   http://tools.ietf.org/html/rfc5246#page-41

   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.3 (see
      Appendix E for details about backward compatibility).

The spec has always been saying "This SHOULD be the latest (highest valued)
version supported by the client".  What is your rationale to *NOT* always
send the latest (highest valued) version supported by the client
in ClientHello.client_version, and in particular on renegotiation handshakes?
In particular, when that highest value worked just finie on the inital
handshake.

When you do that, then you don't get into trouble talking to
windows 7 / windows 2008, where an interoperability problem
had been newly added to SChannel  (windows XP/2003 does not have
this bug).

-Martin

Dr Stephen Henson wrote:
> The problem is whichever one you choose some widely deployed servers
> will choke on it.
>

---

From: Yoav Nir <[email-masked]>
Date: Sat, 11 Feb 2012 17:19:18 +0200

Hi Martin

As a client that's good advice. As a server that does not support TLS 1.2 yet, you get Windows 7 and iOS 5 clients reverting to 3.1 or 3.0 on the ClientHello.client_version, but keeping 3.3 in the PMK. You have to deal with that. Sure, adding TLS 1.2 support is the right way, but you might try for a smaller fix in the short term.

Yoav

---

From: Martin Rex <[email-masked]>
Date: Sun, 12 Feb 2012 01:04:58 +0100 (MET)

Yoav Nir wrote:
> 
> As a client that's good advice. As a server that does not support
> TLS 1.2 yet, you get Windows 7 and iOS 5 clients reverting to 3.1
> or 3.0 on the ClientHello.client_version, but keeping 3.3 in the PMK.
> You have to deal with that. Sure, adding TLS 1.2 support is the right
> way, but you might try for a smaller fix in the short term.

Agreed.  I'm sorry, I forgot about servers that want to offer
renegotiation (I never supported that in our server...).

On renegotiation handshakes, the server ought to skip the  client_version
check on the RSA PMS completely.  Why? because the (lack of) design
of this part of the SSL/TLS protocol does not allow changing of the
protocol version during renegotiation handshakes.

-Martin