Why tls 1.0 is insecure?

In the early 1990s, Netscape began developing SSL; therefore, an initial draft was submitted for SSL v2.0 in 1995. SSL v2.0 had major security flaws that led to the creation of SSL v3.0. The draft for SSL v3.0 was submitted to the IETF in 1996. In Netscape’s words, SSL v3.0 could be a security protocol that prevents eavesdropping, tampering, or message forgery over the Internet. The IETF published RFC 61012 (Request for Comment) as specification for SSL v 3.0. SSL began to be known as TLS, and the next version of TLS came in 1999 with RFC 22463. In a nutshell, SSL v 3.0 and TLS 1.0 don’t have variations that a developer should worry about; however, it’s better to use TLS 1.0. The next version of TLS, TLS 1.1, came into existence in 2006 and is outlined in RFC 43464. TLS 1.1 has enhancements over TLS 1.0. The next version, TLS 1.2, was released in 2008 and is defined through RFC 52465. TLS 1.2 has had major changes since TLS 1.1, and it includes support for newer and secure cryptographic algorithms. In August 2018, TLS 1.3 was released. The differences between TLS 1.2 and 1.3 are extensive and significant, improving each performance and security. Simultaneously, TLS 1.2 remains in widespread use given its absence of known vulnerabilities and its continued usage in enterprise environments.

Sensitive data always require robust protection. TLS protocols provide confidentiality, integrity, and often authenticity protections to information while in transit over a network. This can be achieved by providing a secured channel between a server and a client to communicate for a session. Over time, new TLS versions are developed, and some of the previous versions become outdated for vulnerabilities or technical reasons; and, therefore, should no longer be used to protect data.

TLS 1.2 or TLS 1.3 should be used, and any organizations should not use SSL 2.0, SSL 3.0, TLS 1.0, and TLS 1.1.

In TLS 1.2, the term “cipher suites” refers to the negotiated and agreed-upon set of cryptographic algorithms for the TLS transmission. The TLS client offers a list of cipher suites, and the server selects negotiated cipher suites from the list. The cipher suites in TLS 1.2 consist of an encryption algorithm, a key exchange algorithm, an authentication mechanism, and a key derivation mechanism.

Cipher suites are identified as obsolete when one or more of the mechanisms is weak. Fragile encryption algorithms in TLS 1.2 are defined as NULL, RC2, RC4, DES, IDEA, and TDES/3DES; organizations should not use cipher suits with these algorithms. TLS 1.3 removes these cipher suites, but implementations supporting TLS 1.3 and organizations should check TLS 1.2 for obsolete cipher suites.

Weaker key exchange mechanisms indicated by cipher suite include those designated as EXPORT or ANON. Cipher suites that use these key exchange mechanisms should not be used. In TLS sessions, even if the cipher suite is acceptable, key exchange mechanisms may use weak keys that allow exploitation. TLS key exchange methods include RSA key transport and DH or ECDH key establishment. DH and ECDH have static as well as ephemeral mechanisms. NSA recommends RSA key transport and ephemeral DH (DHE) or ECDH (ECDHE) mechanisms, with RSA or DHE key exchange using at least 3072-bit keys and ECDHE key exchanges using the secp384r1 elliptic curve. For RSA key transport and DH/DHE key exchange, keys less than 2048 bits should not be used, and ECDH/ECDHE using custom curves should not be used.

Outdated TLS protocols use cipher suites that are not supported or recommended, and using older TLS versions would require effort to keep the libraries and drive up the cost of product maintenance. Apart from the above-discussed scenario, some additional ones can be:

Since there are many ways that obsolete TLS configurations may be exhibited in traffic, the following detection strategy is recommended. Signatures can be simplified using this strategy:

Apart from getting rid of vulnerabilities and having better security for the environment, organizations do tend to gain a few benefits by upgrading to newer protocols:

TLS 1.0 has several flaws. An attacker can cause connection failures and they can trigger the use of TLS 1.0 to exploit vulnerabilities like BEAST (Browser Exploit Against SSL/TLS).

By Andrew Marshall Principal Security Program Manager Microsoft Corporation

This document presents the latest guidance on rapidly identifying and removing Transport Layer Security (TLS) protocol version 1.0 dependencies in software built on top of Microsoft operating systems, following up with details on product changes and new features delivered by Microsoft to protect your own customers and online services. It is intended to be used as a starting point for building a migration plan to a TLS 1.2+ network environment. While the solutions discussed here may carry over and help with removing TLS 1.0 usage in non-Microsoft operating systems or crypto libraries, they are not a focus of this document.

TLS 1.0 is a security protocol first defined in 1999 for establishing encryption channels over computer networks. Microsoft has supported this protocol since Windows XP/Server 2003. While no longer the default security protocol in use by modern OSes, TLS 1.0 is still supported for backwards compatibility. Evolving regulatory requirements as well as new security vulnerabilities in TLS 1.0 provide corporations with the incentive to disable TLS 1.0 entirely.

Microsoft recommends customers get ahead of this issue by removing TLS 1.0 dependencies in their environments and disabling TLS 1.0 at the operating system level where possible. Given the length of time TLS 1.0 has been supported by the software industry, it is highly recommended that any TLS 1.0 deprecation plan include the following:

The goal of this document is to provide recommendations which can help remove technical blockers to disabling TLS 1.0 while at the same time increasing visibility into the impact of this change to your own customers. Completing such investigations can help reduce the business impact of the next security vulnerability in TLS 1.0. For the purposes of this document, references to the deprecation of TLS 1.0 also include TLS 1.1.

Enterprise software developers have a strategic need to adopt more future-safe and agile solutions (otherwise known as Crypto Agility) to deal with future security protocol compromises. While this document proposes agile solutions to the elimination of TLS hardcoding, broader Crypto Agility solutions are beyond the scope of this document.

Microsoft's TLS 1.0 implementation is free of known security vulnerabilities. Due to the potential for future protocol downgrade attacks and other TLS 1.0 vulnerabilities not specific to Microsoft's implementation, it is recommended that dependencies on all security protocols older than TLS 1.2 be removed where possible (TLS 1.1/1.0/ SSLv3/SSLv2).

In planning for this migration to TLS 1.2+, developers and system administrators should be aware of the potential for protocol version hardcoding in applications developed by their employees and partners. Hardcoding here means that the TLS version is fixed to a version that is outdated and less secure than newer versions. TLS versions newer than the hardcoded version cannot be used without modifying the program in question. This class of problem cannot be addressed without source code changes and software update deployment. Protocol version hardcoding was commonplace in the past for testing and supportability purposes as many different browsers and operating systems had varying levels of TLS support.

Many operating systems have outdated TLS version defaults or support ceilings that need to be accounted for. Usage of Windows 8/Server 2012 or later means that TLS 1.2 will be the default security protocol version:

*TLS 1.1/1.2 can be enabled on Windows Server 2008 via this optional Windows Update package.

For more information on TLS 1.0/1.1 deprecation in IE/Edge, see Modernizing TLS connections in Microsoft Edge and Internet Explorer 11, Site compatibility-impacting changes coming to Microsoft Edge and Disabling TLS/1.0 and TLS/1.1 in the new Edge Browser

A quick way to determine what TLS version will be requested by various clients when connecting to your online services is by referring to the Handshake Simulation at Qualys SSL Labs. This simulation covers client OS/browser combinations across manufacturers. See Appendix A at the end of this document for a detailed example showing the TLS protocol versions negotiated by various simulated client OS/browser combinations when connecting to www.microsoft.com.

If not already complete, it is highly recommended to conduct an inventory of operating systems used by your enterprise, customers and partners (the latter two via outreach/communication or at least HTTP User-Agent string collection). This inventory can be further supplemented by traffic analysis at your enterprise network edge. In such a situation, traffic analysis will yield the TLS versions successfully negotiated by customers/partners connecting to your services, but the traffic itself will remain encrypted.

Since the v1 release of this document, Microsoft has shipped a number of software updates and new features in support of TLS 1.0 deprecation. These include:

For products using the Windows OS-provided cryptography libraries and security protocols, the following steps should help identify any hardcoded TLS 1.0 usage in your applications:

The recommended solution in all cases above is to remove the hardcoded protocol version selection and defer to the operating system default. If you are using DevSkim, click here to see rules covering the above checks which you can use with your own code.

Windows PowerShell uses .NET Framework 4.5, which does not include TLS 1.2 as an available protocol. To work around this, two solutions are available:

Solutions (1) and (2) are mutually-exclusive, meaning they need not be implemented together.

Applications using .NET framework versions prior to 4.7 may have limitations effectively capping support to TLS 1.0 regardless of the underlying OS defaults. Refer to the below diagram and Transport Layer Security (TLS) best practices with the .NET Framework for more information.

SystemDefaultTLSVersion takes precedence over app-level targeting of TLS versions. The recommended best practice is to always defer to the OS default TLS version. It is also the only crypto-agile solution that lets your apps take advantage of future TLS 1.3 support.

If you are targeting older versions of .NET Framework such as 4.5.2 or 3.5, then by default your application will use the older and not recommended protocols such as SSL 3.0 or TLS 1.0. It is strongly recommended that you upgrade to newer versions of .NET Framework such as .NET Framework 4.6 or set the appropriate registry keys for 'UseStrongCrypto'.

Following the fixes recommended in the section above, products should be regression-tested for protocol negotiation errors and compatibility with other operating systems in your enterprise.

A simple blueprint for testing these changes in an online service consists of the following:

After TLS hardcoding is addressed and operating system/development framework updates are completed, should you opt to deprecate TLS 1.0 it will be necessary to coordinate with customers and partners:

Removing TLS 1.0 dependencies is a complicated issue to drive end to end. Microsoft and industry partners are taking action on this today to ensure our entire product stack is more secure by default, from our OS components and development frameworks up to the applications/services built on top of them. Following the recommendations made in this document will help your enterprise chart the right course and know what challenges to expect. It will also help your own customers become more prepared for the transition.

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.

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.

(This post has been updated. It was originally published on February 19, 2020.)