I saw today that TLS 1.1 and 1.2 are not enabled by default in Windows 7 and Windows Server 2008. They can be enabled after an optional update, and after setting a registry key.

Why? Negotiating the TLS version is supposed to find the highest version supported by both parties. What harm does automatically supporting a new version bring? Why would an app explicitly specify the versions to use instead of the future-proof "whatever the underlying crypto library uses"?

I kind of understand disabling by default draft protocols (to avoid making these draft versions a de facto standard). But the Windows update was released in 2016 and TLS 1.2 in 2008.

2 Answers 2


I believe the reason for not enabling support for TLS1.1 and TLS1.2 in a TLS client by default was widespread TLS version intolerance among the installed TLS servers at the time. As Adam Langely (person in charge of server and client (Chrome and Android) TLS stack in Google, forker of OpenSSL into BoringSSL and author of Go's TLS stack) wrote in 2011:

Despite it being nearly twelve years since the publication of TLS 1.0 [RFC2246], around 3% of HTTPS servers will reject a valid TLS "ClientHello". These rejections can take the form of immediately closing the connection or a fatal alert. Intolerance to the following has been observed:

Advertising version TLS 1.0.

Advertising a TLS version greater than TLS 1.0 (around 2% for 1.1 or 1.2, around 3% for greater than 1.2).

Advertising a version greater than 0x03ff (around 65% of servers)

The presence of any extensions (around 7% of servers)

The presence of specific extensions ("server_name" and "status_request" intolerance has been observed, although in very low numbers).

The presence of any advertised compression algorithms

This issue with TLS version intolerance caused browsers to fallback retry, which caused Adam Langely to invent SCSV to protect against downgrade during fallback. TLS 1.3 had issues with proxies and switched the version negotiation mechanism to work differently and left two wasted bytes in the TLS record to say "TLS1.2", fixed forever.

To try to combat ossification and intolerant servers being deployed, Google's David Benjamin introduced GREASE, a system that injects fake never-allocated identifiers into options lists in TLS ClientHello to force TLS servers to correctly implement the required "disregard unknown values proposed by client and continue with the known values" behavior.


In times of release early, release often of products it might sound strange: but most customers actually prefer products which show a stable behavior for a long time. This kind of predictability is especially important for the operating systems and widely used libraries. Developers need such predictability when testing their code and cannot test all possible variations of their are too many or if the OS and the libraries are a moving target. Customers need the predictability to not add another problem on top of all the other problems they already have. In most cases business continuity is much more important than security improvements.

Therefore it is pretty common in industry that new features (like support for new TLS versions) are only shipped in new releases and not in patches. Patches are typically considered only for essential bug fixes in order to keep the underlying system behavior as similar as possible to the system before the patch.

And adding support for a new TLS protocol version is not a trivial change. It actually happened a lot in the past that broken TCP stacks where used (especially in embedded systems) which were not able to properly deal with newer TLS versions or new ciphers. Browsers had to actually add workarounds for such servers by automatically retrying with a lower TLS version if TLS 1.2 did not work.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .