It's unclear to me if there are multiple problems, or a single one, (and just what that problem is) with servers incorrectly negotiating down from a client offering 1.1 or 1.2 to something they support like SSL 3 or TLS 1.0.

Eric Lawrence has said that some version outright chokes on TLS 1.1 and 1.2. Adam Langley points it out again:

Due to a different, common bug in SSL 3.0 implementations (nearly 12 years after SSL 3.0 was obsoleted by TLS 1.0), browsers still have to perform SSL 3.0 downgrades to support buggy servers. So even with a TLS 1.1 capable browser and server, an attacker can trigger a downgrade to SSL 3.0 and bypass the protections of TLS 1.1.

And there are significant notes in the TLS 1.2 RFC also.

Note: some server implementations are known to implement version negotiation incorrectly. For example, there are buggy TLS 1.0 servers that simply close the connection when the client offers a version newer than TLS 1.0. Also, it is known that some servers will refuse the connection if any TLS extensions are included in ClientHello. Interoperability with such buggy servers is a complex topic beyond the scope of this document, and may require multiple connection attempts by the client.

And finally, Eric Rescorla who's somewhat 'up' on TLS adds:

First let's dispose of the TLS 1.1 angle. As has been apparent from the beginning, the ultimate fix is to upgrade everyone to TLS 1.1. Unfortunately, the upgrade cycle is really long, especially as many of the popular stacks don't have TLS 1.1 support at all. To make matters worse, due to a number of unfortunate implementation decisions which I'll hopefully get time to write about later, it's likely to be possible for an attacker to force two TLS 1.1 implementations to speak TLS 1.0, making them vulnerable. So, upgrading to TLS 1.1 is basically a non-starter.

Are all these notes about the same problem? Is that problem as straightforward as a server choking on a 1.1 or 1.2 offering ( { 3, 2} or { 3, 3} ), or is there more to it? Is there any documentation or notes about just what servers choke on TLS 1.1?

  • 1
    $\begingroup$ It sounds like at least two different problems, possibly more. I think the second problem you outline, the one mentioned in the TLS 1.2 RFC, is the one mentioned in your last paragraph. $\endgroup$ Commented Feb 18, 2012 at 17:49
  • $\begingroup$ When OpenSSL 1.0.1 release March 2012 jumped its default from TLS1(.0) to 1.2, there were numerous reports of client attempts failing because server FIN'd, RST, or hung. On many downgrading to 1.1 worked, so it wasn't just version number. The main difference between 1.1 and 1.2 is 32 new suites and a new extension for sigalgs, and on investigation it turned out this put the ClientHello size over 256 bytes, and that forcing such a size in 1.1 (usually by padding SNI) also triggered the problems. $\endgroup$ Commented Aug 20, 2014 at 1:33

1 Answer 1


The problem is not as simple as just the version number, though according to Eric Rescorla, there are some of those. In my experience, most problematic implementations have a problem with ClientHello extensions, which were formally defined after TLS 1.0 was a standard. As such, some servers are hardcoded to expect ClientHello and no more data, which means they will choke on any TLS extensions being sent to them.

Since SSLv3 didn't have the notion of extensions, none of the implementations that I'm aware of send any extensions in their ClientHello. This causes usage of SSLv3 to succeed even against servers that fail on receiving TLS extensions. As such, because of browsers' desire to connect to any server, they try to connect with TLS and extensions and if that fails, they will fallback and try with SSLv3.

For browsers that support TLS 1.1/1.2, it is even more fallback logic, as it maybe that the server didn't accept 1.1, but accepts 1.0 just fine, so you have multiple cascading fallbacks.

So to sum it up - version number and TLS extensions handling are the two most common problems and yes, the above statements are all referring to these types of problems and the browser behavior.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.