TLS 1.0 and SSL Vulnerabilities: What You Need to Know

Is your organization still using old SSL/TLS protocols? 

The PCI Security Standards Council requires all payment processors and merchants to move to TLS 1.2 and above. Organizations that don't follow this standard do not meet PCI DSS.

TLS & SSL: Fundamental Security Protocols

Transfer Layer Security (TLS) is a cryptographic protocol designed to provide secure communication between web browsers and servers. The TLS protocol achieves three primary objectives: Encryption, Authentication, and Integrity. It is used in almost every app nowadays. Many IP-based protocols such as HTTPS, SMTP, POP3 and FTP support TLS.

Secure Sockets Layer (SSL), on the other hand, is a protocol used to establish an encrypted link between web browsers and servers. It uses symmetric cryptography to encrypt the data transmitted. Encryption keys are based on shared secret negotiation at the beginning of any communication session. This secret negotiation is referred to as the TLS handshake.

Old, but still common TLS versions are the TLS 1.0, launched in 1999, and its update, TLS 1.1, which was launched in 2006. It is recommended to disable TLS 1.0 and TLS 1.1.

While TLS 1.2 and TLS 1.3 are current and more secure, many organizations still inadvertently support TLS 1.0 and the obsolete TLS 1.1 due to compatibility requirements or oversight.

Supported versions of TLS in Windows

(Reference: Microsoft (11/02/2023) Solving the TLS 1.0 Problem, 2nd Edition)

Vulnerabilities and The Most Common SSL and TLS Attacks

Various a Man-in-the-Middle (MITM) attacks exploit the vulnerabilities in these protocols.

TLS/SSL had suffered from numerous malware attacks that exploited its vulnerabilities. Examples include:

•  CVE-2023-24023 A recent BLUFFS attack empowers hackers to take control of Bluetooth connections. Bluetooth BR/EDR devices utilizing Secure Simple Pairing and Secure Connections pairing from Bluetooth Core Specification 4.2 through 5.4 are susceptible to specific man-in-the-middle attacks, potentially resulting in the enforcement of a shortened key length and the risk of exposing the encryption key, allowing for live injection.

• Padding oracle attack is a form of attack on encrypted data that enables the attacker to decrypt the content without possessing the key. An oracle serves as a “tell,” providing an attacker with information about the correctness of their executed action. The term “padding” is a specific cryptographic term. When combined, a software implementation with a padding oracle discloses whether decrypted data contains valid padding. Block-based ciphers have a mode, like Cipher-Block-Chaining (CBC), determining the relationship between data in consecutive blocks.

• CVE-2022-33682 Apache Pulsar Vulnerability Enables MitM Attacks. A critical vulnerability in the org.apache.pulsar:pulsar-proxy package, allowing attackers to eavesdrop on communication between clients and the Pulsar server. This is MitM attack, where an attacker intercepts and potentially steals data flowing through the system. The vulnerability stems from disabled TLS hostname verification by default.

• Compressing Ratio Info-leak Made East (CRIME) exploits the vulnerability in TLS compression. TLS compression method in the ClientHello message is only optional, meaning that the connection can be established without any compression. The main purpose of compression is to reduce bandwidth usage while preserving integrity and security when exchanging large amounts of information. CRIME captures the SeverHello message (in response to the ClientHello), and disables the compression option. The attacker can then take advantage of the compromised traffic.

• TLS heartbeat extension is also a known vulnerability in old TLS versions. The heartbeat function is used to ensure that a connection between two parties continues, as long as they are still there. Heartbeat request is performed when the user sends a heartbeat message and the size of the data to the server. The server then responds with the same heartbeat request, sending data and its size. Heartbeat vulnerability is reflected when a client sends false data length, and the server then responds with the same data received from the user in addition to some random data from its memory, to meet the data size announced by the user, even though his data didn't meet his own statements.

Securing Sensitive Data: How to Mitigate Risks?

The proper way to address those vulnerabilities is to harden TLS v1.0, TLS v1.1, SSL v2.0 & SSL v3.0 by disabling them.

In order to disable TLS v1.0 & 1.1, you need to create an Enabled entry in TLS 1.0 or TLS 1.1 subkeys (depending on the protocol you want to disable). This entry does not exist in the registry by default. After you have created the entry, change the DWORD value to 0. In order to enable the protocol, change the DWORD to 1. The same can be done to SSL 2.0 and SSL 3.0.

Why are those protocols still here?

Newer, more resilient TLS protocols have already been released. TLS 1.2 and 1.3 were released in late 2008 and 2018 respectively. So, how come so many companies still insist on relying on breached protocol versions such as the 1.0 and 1.1? Well, apparently this is because TLS/SSL usage is so extended, changing configurations could cause extensive damage.

Changing configurations on enterprises' server demand the support of all the services to the new version. For example, web browsers that don't comply with the new configuration basically force organizations that need the connection to those browsers to stay exposed. Another issue is the lack of awareness of the vulnerability or full awareness, but lack of regulations. In the absence of regulation to make them implement the changes, organizations might decide to avoid the mess of hardening SSL/TLS, thus leaving their infrastructure exposed to breaches.

Leaving TLS 1.2 and moving to TLS 1.3?

What might break when hardening SSL/TLS protocols?

Since SSL/TLS protocols support a wide variety of services as well as other protocols, you should take bear in mind that disabling it will probably force you to find solutions for services that depend on it. In particular, client-side applications and public-facing web servers that have not been configured to accommodate newer TLS versions might experience disruption.

Here are a few examples of things that might break when hardening TLS/SSL protocols:

• Public-facing websites using HTTPS
• Remote desktop services
• Anywhere Access RDP connection
• Office 365 integration
• Server 2008 R2, IIS 7.5 – when disabling both SSLv3 and TLS 1.0

IT forums and communities contain many more examples of damages that can be caused by hardening SSL/TLS. Eventually, many organizations prefer to remain vulnerable than to take the risk that although tests will be performed, things will still continue breaking.

How to avoid outages when hardening TLS & SSL?

CalCom's software learning ability is capable of producing an accurate report regarding hardening SSL/TLS protocols’ consequences, so you won't find out about it only when it breaks. It will also present the status of each server and whether it is hardened according to best practices recommendations or not. When finally deciding your course of action, CHS will automatically enforce your decision on the production environment. Learn more about it.