Overview
Secure web communications have come a long way since the 1990s. From a rocky start to implementing protections against quantum computing, SSL and TLS have a storied history that affects everyone from the developer to the executive in C suites. The modern implementations of the TLS protocol suites are a first line of defense to many organizations’ enterprise IT presence. More importantly it represents one of the strongest layers of defense your organization has to offer in protecting its crown jewels – proprietary and in some cases extremely sensitive data. In this article I will go over some of the history of TLS, why adoption remains an issue, why it’s important to include this in your organization’s roadmap, and what can be done to protect your organization; whether you are a small business or large government agency.
History
Before we address TLS 1.3 and its benefits, we should take a walk down memory lane and review the history of TLS and SSL. In 1994, Netscape was the dominant browser in the burgeoning world wide web. Initially, they were concerned about the need for secure online communication and concentrated on securing traffic within the browser to websites. They developed SSL 1.0 in an effort to meet this requirement.
SSL 1.0 was not released publicly due to a variety of basic security flaws including the lack of sequence numbers to protect against relay attacks and the use of insecure ciphers, such as RC4 (Oppliger, 2009). While SSL 1.0 was considered a failure, Netscape made improvements and corrections, releasing SSL 2.0 to the public in 1995. Unfortunately SSL 2.0 was plagued by its own set of security flaws. On top of the security flaws it was only able to accept a single domain certificate; making the protocol practically useless for websites being hosted as virtual web servers. (Subramanium, n.d.).
SSL 3.0 was developed to address the issues with SSL 2.0. It was released in 1996 and became the standard bearer for almost a decade. Furthermore, SSL 3.0 drastically improved its usefulness by bringing compatibility for multiple SAN (Subject Alternative Name) certificates and improved ciphers, data integrity, and man-in-the-middle protection. SSL 3.0 became the standard bearer for the better part of 10 years, then the industry began paying attention to something called a POODLE attack. It’s interesting to note that it took 10 years for the industry at large to acknowledge the vulnerability.
Introduction of Transport Layer Security
By the late 1990s, the Internet Engineering Task Force (IETF) became the primary author for SSL/TLS standards. In 1999, citing significant improvements to SSL 3.0, IETF approved the TLS 1.0 standard. As opposed to previous version changes that included both security and functionality changes, TLS 1.0’s major differences were all security related. The key derivation and message authentication code mechanisms were greatly improved. Hash based Message Authentication Codes (HMAC) were implemented as a far more secure method that did not depend on a single hashed value of the message and secret key. HMAC brought about a more complex construction that involved two passes of the hashing function, along with the use of both inner and outer padding. (What is the difference between a MAC and HMAC, and how does HMAC enhance the security of MACs?, 2023)
TLS 1.1 was released in 2006, bringing about two significant changes to the standard. First, TLS 1.1 added protections against cipher-block chaining attacks by changing padding error behaviors. Secondly, notably the addition of an explicit Initialization Vector to protect against BEAST attacks. (Banach, 2024) Two years later, TLS 1.2 was released with a large number of changes including the implementation of AES ciphers and upgraded hashing algorithms.
In 2014, SSL 3.0 and TLS 1.0 and 1.1 were widely used across many environments. The publication of a successful exploitation of a POODLE attack rattled cyber security experts and IT shops around the world. The specifics of the POODLE attack involved how the protocol managed padding schemes and cipher-block chaining attacks. This issue was further exacerbated by the fact that the TLS versions of the time allowed downgrading of SSL/TLS versions to support SSL 3.0; effectively negating any and all of the security benefits of later TLS implementations. The attacker effectively instructed a TLS server that the client only supported SSL 3.0 in order to complete a padding attack. (SSL 3.0 Protocol Vulnerability and POODLE Attack, 2016)
The response to this realization resulted in a wide spread effort to remove SSL 3.0 completely in sensitive companies and government agencies. The reaction was so great that retroactive RFC updates removed backwards compatibility in all TLS versions, effectively ending any implied support for SSL 3.0. This was the first time, in SSL/TLS history, that the IETF adopted a mindset that in order to leverage new security features, backwards compatibility would be explicitly denied. The outcome was dramatic, companies and organizations with any type of web presence started moving toward TLS and away from the deprecated SSL standards, evidence of an intensified awareness toward cyber threats.
TSL 1.3
TLS 1.3 was released in 2018 as the modern implementation of transport security. We can find widespread adoption of mobile and desktop clients consuming all types of cloud services; not just web traffic but mail, file transfer and everything in between. TLS is widely considered a hard and fast requirement ahead of going to production with any type of service.
The TLS 1.3 standard, a giant leap forward in terms of security, was a response to the new cyber security challenges in 2018. caused a giant leap forward in terms of security. This is factored into the with. First, TLS 1.3 removed a litany of older cipher suites and encryption mechanisms, not considered secure.
Granted, Artificial Intelligence and quantum computing still stood over secure computing in 2018 threatening to break through previously considered secure ciphers and encryption standards. Developers of the standard paid particular attention to this threat. Specifically, they analysed TLS 1.2’s vulnerabilities and developed the standard accordingly:
- TLS 1.2’s Vulnerability: Quantum computers can potentially break the RSA and ECC algorithms that TLS 1.2 relies on for key exchange. This means that a quantum computer could decrypt communications that were encrypted with TLS 1.2.
- TLS 1.3’s Resilience: TLS 1.3 uses stronger key exchange algorithms that are believed to be more resistant to quantum attacks. Additionally, TLS 1.3 has removed support for weaker algorithms and has a more streamlined handshake process, which reduces the attack surface.
Once again, a line was drawn in the sand, this time backwards compatibility for any older version of TLS was disallowed – this time data security was no longer simply a goal, it was a mandate. However, as with the previous removal of backward compatibility, organizations faced a number of challenges:
Legacy Systems: Older systems and software may not support TLS 1.3. This can lead to connection failures or fallback to older, less secure TLS versions.
Middleboxes: Some network devices, such as firewalls and load balancers, may not be configured to properly handle TLS 1.3 traffic, potentially causing disruptions.
Application Compatibility: Certain applications may have dependencies on specific TLS features or extensions that are not supported or have changed in TLS 1.3.