The SSL/TLS security protocols have been designed and implemented to provide end-to-end data security. This includes data integrity, that is, the data cannot be modified, replayed or reordered by an attacker without being detected at the receiving endpoint. As with any technology, SSL/TLS has its flaws. Successful attacks on a security protocol defy its purpose and jeopardizes the integrity, confidentiality and authenticity of information transmitted. The deprecation of tls 1.0 and 1.1 serves as a reminder of the necessity for keeping security protocols up-to-date.
Securely sending information over the Internet is a foundation of online commerce, medicine, and other sensitive transactions. It is, therefore, critical that transmitted information not be tampered with, forged, or read by anyone other than the sender and receiver. These features are critical and have been a key part of the Internet's growth.
One of the most important ways to keep your data effectively encrypted is to replace older encryption standards with newer ones. The increased processing power of computers allows for faster cracking of otherwise strong security protocols. On the other hand, security researchers and cyber attackers alike discover new vulnerabilities everyday waiting to be exploited. Everyone who understands even the basics of cryptography knows that every security protocol and cipher has an expiration date, or as Kim Crawley puts it, a “best before date.”
Deprecation of TLS 1.0 and TLS 1.1
Internet Engineering Task Force (IETF) has released a document where they explicitly state that TLS 1.0 and TLS 1.1 must not be used and they plan to deprecate both protocols by the end of 2019.
It is true that both protocols can be considered as “ancient history” in terms of internet and computer times. TLS 1.0 is already twenty years old as it was first deployed in January 1999. Not surprisingly, the Payment Card Industry (PCI) has deprecated TLS 1.0 since 30 June 2018. Now any e-commerce site or retailer which still uses TLS 1.0 to encrypt credit card transactions will fail PCI compliance. Therefore, PCI has provided guidance to use TLS 1.1, 1.2, or 1.3 in order to securely process credit card payments.
On the other hand, TLS 1.1 was released in April 2006. It only had minor improvements from TLS 1.0, and was developed to address weaknesses discovered in TLS 1.0, primarily in the areas of initialization vector selection and padding error processing.
Both protocols have various vulnerabilities and the specific details on attacks against them as well as their mitigations are provided in NIST SP800-52r2 among other documents.
In line with the IETF, Microsoft, Apple, Google, and Mozilla declared that their “best before date” for both TLS 1.0 and TLS 1.1 is March 2020. The major web browser developers have announced that they will drop TLS 1.0 and TLS 1.1 nearly a year and a half in advance in order to give web-hosting companies and cloud services providers plenty of time to phase the old versions out.
Martin Thomson wrote for Mozilla’s blog: “In March of 2020, Firefox will disable support for TLS 1.0 and TLS 1.1. Though we are not aware of specific problems with TLS 1.0 that require immediate action, several aspects of the design are neither as strong or as robust as we would like given the nature of the Internet today. Most importantly, TLS 1.0 does not support modern cryptographic algorithms.”
In addition, Google’s announcement reads that “TLS 1.2 was published ten years ago to address weaknesses in TLS 1.0 and 1.1 and has enjoyed wide adoption since then. Today only 0.5% of HTTPS connections made by Chrome use TLS 1.0 or 1.1. These old versions of TLS rely on MD5 and SHA-1, both now broken, and contain other flaws. TLS 1.0 is no longer PCI-DSS compliant and the TLS working group has adopted a document to deprecate TLS 1.0 and TLS 1.1.”
How to Disable TLS 1.0 and 1.1
There are two methods for disabling TLS 1.0 or 1.1 recommended by SolarWinds:
Disable TLS 1.0 or 1.1 via Registry
- Open registry editor.
- Go to HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols.
- TLS 1.0 or 1.1 entry does not exist in the registry by default.
- Create a new subkey called "TLS 1.0 or 1.1" under Protocols.
- Create a new subkey called "Server" under TLS 1.0 or 1.1.
- In the Server key, create a DWORD DisabledByDefault entry, set the value to 1.
- Reboot the server.
Disable TLS 1.0 or 1.1 using IIS Crypto (3rd Party Tool)
- Download IIS Crypto GUI from this link.
- Open IIS Crypto.
- Uncheck the Server Protocols.
- Reboot the server.
What are the risks of using TLS 1.0, 1.1, and other outdated security protocols?
The IETF draft document describes the security reasons in detail.
These versions lack support for current and recommended cipher suites, and supporting these older versions also requires additional effort for library and product maintenance.
- They require implementation of older cipher suites that are no longer desirable for cryptographic reasons and they lack support of current recommended cipher suites. Various government and industry organizations and agencies mandate avoiding these old TLS versions. Products having to support older versions increase the attack surface unnecessarily and increase opportunities for misconfigurations.
- The integrity of both TLS 1.0 and TLS 1.1 depends on a running SHA-1 hash of the exchanged messages. This makes it possible to perform a downgrade attack on the handshake by an attacker well below the acceptable modern security margin.
- The authentication of the handshake depends on signatures made using SHA-1 hash or a not stronger concatenation of MD-5 and SHA-1 hashes, allowing the attacker to impersonate a server when it is able to break the severely weakened SHA-1 hash.
- Neither TLS 1.0 nor TLS 1.1 allow the peers to select a stronger hash for signatures, making the use of a newer protocol version a one-way road.
- Deprecation also assists product teams with phasing out support for the older versions to reduce the attack surface and the scope of maintenance for outdated protocols.
As Apple notes in their announcement, the use of modern and more secure versions of this protocol, such as TLS 1.2 or the newly specified TLS 1.3 is the preferred way ahead. TLS 1.2 made several cryptographic enhancements, particularly in the area of hash functions, with the ability to use or specify the SHA-2 family algorithms for hash. TLS 1.2 also adds authenticated encryption with associated data (AEAD) cipher suites. TLS 1.3 represents a significant change to TLS that aims to address threats that have arisen over the years. Among the changes are a new handshake protocol, a new key derivation process, and the removal of cipher suites that use static RSA or DH key exchanges, the CBC mode of operation, or SHA-1.
The employment of these versions come with many benefits:
- Modern cryptographic cipher suites and algorithms with desirable performance and security properties, such as perfect forward secrecy and authenticated encryption, that are not vulnerable to attacks such as BEAST.
- Removal of mandatory and insecure SHA-1 and MD5 hash functions as part of peer authentication.
- Resistance to downgrade-related attacks such as FREAK.
Security is not a single property possessed by a single protocol. Rather, security includes a complex set of related properties that together provide the required information assurance and protection. Security requirements are derived from a risk assessment of the threats or attacks that an adversary is likely to mount against a system. The cost of promoting interoperability at the expense of security should be prohibitive.
The existence of TLS 1.0 and 1.1 on the internet acts as a security risk. Clients using these versions are suffering from their shortcomings, while the rest of the internet is vulnerable to various attacks exploiting known TLS vulnerabilities, for almost no practical benefit. In many occasions, the existence of older versions of TLS is due to “just in case” interoperability or because someone forgot to disable them when they activated newer versions.
Replacing older versions of TLS with newer ones takes a lot of work. When major changes like upgrading TLS are deployed, they also must be thoroughly tested. So updating to TLS 1.2 or TLS 1.3 absolutely cannot be done overnight.
(This post has been updated. It was originally published on February 19, 2020.)