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.
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 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 every day new vulnerabilities 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.”
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.”
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.
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:
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 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.)