Skip to main content
banner image
venafi logo

Why It’s Dangerous to Use Outdated TLS Security Protocols

Why It’s Dangerous to Use Outdated TLS Security Protocols

image of a bunch of colored floppy disks laying on a light pink background
May 19, 2020 | Guest Blogger: Anastasios Arampatzis


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.”



 

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.”
 

What are the risks of using 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.
     
Conclusion

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. 
 

Venafi can help you overcome successfully any of these obstacles. Contact the experts to learn how.

 

 

Related posts

 

Like this blog? We think you will love this.
image of hands typing on a keyboard in the dark
Featured Blog

The Abuse of Root Certificates, Certificate Mis-issuance and Certificate Transparency

First, a bit about root certificates.

Read More
Subscribe to our Weekly Blog Updates!

Join thousands of other security professionals

Get top blogs delivered to your inbox every week

See Popular Tags

You might also like

CIO Study: Certificate-Related Outages Continue to Plague Organizations
White Paper

CIO Study: Certificate-Related Outages Continue to Plague Organizations

Machine Identity Protection for Dummies
eBook

Machine Identity Protection for Dummies

About the author

Guest Blogger: Anastasios Arampatzis
Guest Blogger: Anastasios Arampatzis

Anastasios Arampatzis is a retired Hellenic Air Force officer with over 20 years of experience in evaluating cybersecurity and managing IT projects. He works as an informatics instructor at AKMI Educational Institute, while his interests include exploring the human side of cybersecurity.

Read Posts by Author
get-started-overlay close-overlay cross icon
get-started-overlay close-overlay cross icon
Venafi Risk assessment Form Image

Sign up for Venafi Cloud


Venafi Cloud manages and protects certificates



* Please fill in this field Please enter valid email address
* Please fill in this field Password must be
At least 8 characters long
At least one digit
At last one lowercase letter
At least one uppercase letter
At least one special character
(@%+^!#$?:,(){}[]~`-_)
* Please fill in this field
* Please fill in this field
* Please fill in this field
*

End User License Agreement needs to be viewed and accepted



Already have an account? Login Here

×
get-started-overlay close-overlay cross icon

How can we help you?

Thank you!

Venafi will reach out to you within 24 hours. If you need an immediate answer please use our chat to get a live person.

In the meantime, please explore more of our solutions

Explore Solutions

learn more

Email Us a Question

learn more

Chat With Us

learn more
Chat