Transport Layer Security (TLS)↑

Transport Layer Security (TLS) is a widely used cryptographic protocol responsible for securing communication over the Internet. It ensures confidentiality, integrity, and authentication between clients and services, preventing unauthorized access and data interception. TLS is the successor to the now-obsolete Secure Sockets Layer (SSL) protocol and has evolved significantly to mitigate security weaknesses in earlier versions.

TLS is essential for secure browsing (HTTPS) and is widely used in online transactions, VPN security, and enterprise encryption. However, misconfigurations, outdated versions, and weak cipher suites can expose organizations to vulnerabilities. To ensure security, use TLS 1.2 with secure configurations or, preferably, TLS 1.3 (the latest version), which eliminates legacy weaknesses and enhances security and performance.

Introduction to TLS↑

TLS encrypts data in transit to ensure secure communication between clients and servers. It’s also widely used to protect web traffic, email (SMTP, IMAP, POP3), VoIP, and APIs. In general, TLS aims to provide:

Confidentiality: Encrypts transmitted data, ensuring that even if an attacker intercepts it, they cannot read the plaintext.
Authentication: Authenticates the server using certificates, and optionally the client identity.
Integrity: Detects tampering of data in transit using cryptographic integrity checks, ensuring that altered data is rejected.

TLS 1.3, the latest version, was introduced to improve security and performance by removing outdated cryptographic primitives and simplifying cipher suite selection. It also supports post-quantum cryptography, ensuring resilience against future cryptographic threats. Ongoing research, like the IETF’s “Hybrid Key Exchange in TLS 1.3”, aims to integrate post-quantum security into TLS 1.3 through hybrid key exchange mechanisms that combine classical and post-quantum algorithms. TLS 1.2 will not officially support post-quantum cryptography.

A brief history: from SSL to TLS↑

TLS replaced Secure Sockets Layer (SSL) due to security flaws. SSL 2.0 and 3.0 were deprecated after attacks like POODLE (CVE-2014-3566) revealed them as unsafe.

TLS version history↑

TLS 1.0 (1999) – Described in RFC 2246. Based on SSL 3.0 but vulnerable to BEAST (CVE-2011-3389).
TLS 1.1 (2006) – Described in RFC 4346. Introduced improvements but saw limited adoption.
TLS 1.2 (2008) – Described in RFC 5246. Strengthened security, replacing MD5 and SHA-1 with stronger cryptographic hash functions.
TLS 1.3 (2018) – Described in RFC 8446. Removed outdated ciphers (e.g., RSA key exchange, CBC mode), enforced forward secrecy, and improved handshake speed.

Current status↑

TLS 1.0 & 1.1 - Deprecated (RFC 8996), should no longer be used.
TLS 1.2 - Still supported, but should be securely configured.
TLS 1.3 - Preferred for security and efficiency.

Organizations should disable older TLS versions and ensure compliance with modern security standards.

TLS adoption and usage statistics↑

Table 1 shows data from different sources that provide insights into SSL/TLS version adoption.

TLS Version	Chosen Protocol (F5 report, 2021)	Supported Protocol (SSL Pulse, May 2024)
TLS 1.3	63% of connections actively use TLS 1.3	70.1% of websites support TLS 1.3
TLS 1.2	36% of connections actively use TLS 1.2	99.9% of websites support TLS 1.2
TLS 1.1	0.4% of connections still use TLS 1.0 or 1.1	30% of websites still support TLS 1.1
TLS 1.0	0.4% of connections still use TLS 1.0 or 1.1	27.9% of websites still support TLS 1.0
SSL 3.0	0.002% of connections still use SSL 3.0	1.4% of websites still support SSL 3.0
SSL 2.0	Practically extinct	0.1% of websites still support SSL 2.0

The key differences between the two reports in Table 1 are:

F5 TLS Telemetry Report (2021) → Measures which TLS version is actually chosen and used in active connections across the Tranco top one million global sites.
SSL Pulse Report (May 2024) → Measures which TLS versions are offered as supported by the server, even if they aren’t actually used, across the top 150,000 websites from Alexa rankings.

Offered vs. negotiated cipher suites↑

A cipher suite specifies the cryptographic algorithms for a secure communications channel. Think of the cipher suite as a recipe for security. Using poor or outdated ingredients like deprecated algorithms, incorrect configurations, or improper parameters leads to undesirable—and potentially harmful—results.

Table 1 highlights the widespread use of outdated SSL/TLS versions, which poses a significant security risk by allowing the negotiation and use of insecure cryptographic options, including weak cipher suites.

It’s important to distinguish between cipher suites that a server offers and cipher suites that are actually used in connections:

Offered Cipher Suites: The list of cipher suites that a server advertises as supported. These may include outdated or insecure options if the server hasn’t been properly configured.
Negotiated (Used) Cipher Suites: The cipher suites actually selected and used in a TLS handshake between the client and server. This depends on both the server’s and the client’s configurations. In AQtive Guard, some rules may also refer to ‘use’ instead of negotiated, e.g. Use of ciphersuite with 3DES.

Many websites continue to offer older TLS versions and weaker cipher suites, often for compatibility reasons. In reality, this is usually due to legacy infrastructure, lack of awareness, failure to upgrade systems, reliance on outdated internal policies, or simple inertia—where organizations leave weak cryptographic configurations in place because of resource constraints or fear of breaking existing integrations.

Even if a server defaults to a secure protocol, the presence of outdated cipher suites in the offered list introduces risks, as it may allow older, insecure clients to negotiate weak encryption settings.

Cipher suites in TLS↑

A cipher suite specifies the set of cryptographic algorithms used in a TLS connection to establish a secure communication channel. It defines the combination of encryption, authentication, and key exchange mechanisms that ensure data confidentiality, integrity, and authenticity during transmission. By determining the security parameters for data in transit, cipher suites play a critical role in maintaining secure communications.

While TLS 1.2 has over 300 registered cipher suites, many have been officially deprecated due to security weaknesses, leaving only around 20 still recommended for secure use. Older cipher suites that rely on outdated cryptographic primitives, such as RSA key exchange, CBC-mode encryption, and SHA-1 hashing, have been formally deprecated in various security guidelines, including IETF RFCs and NIST recommendations, due to their vulnerabilities to downgrade attacks, padding oracle attacks, and cryptographic breakage.

However, deprecated doesn’t mean disabled—many systems continue to support and even negotiate these insecure cipher suites if they haven’t been explicitly removed. Since weak cipher suites can still be offered even if they’re rarely used, security teams should audit their TLS configurations regularly and make sure only strong cipher suites are enabled. In contrast, TLS 1.3 officially supports only five cipher suites, as weak and redundant algorithms were eliminated to enforce stronger security.

TLS cipher suite naming conventions↑

TLS cipher suite names follow a structured format to indicate which cryptographic algorithms are used. Table 2 shows an example of how TLS 1.2 cipher suites are named using the example TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256.

Table 2 shows the naming convention of TLS 1.2 cipher suites.

Component	Meaning
TLS	Protocol name (TLS)
ECDHE	Key Exchange Algorithm (Elliptic Curve Diffie-Hellman Ephemeral)
ECDSA	Authentication Algorithm (Elliptic Curve Digital Signature Algorithm)
AES_128_GCM	Encryption Algorithm (AES with 128-bit key in GCM mode)
SHA256	Message Authentication Code (MAC) (SHA-256)

Table 3 shows an example of how TLS 1.3 cipher suites are named using the example TLS_AES_256_GCM_SHA384.

Table 3 shows the naming convention of TLS 1.3 cipher suites.

Component	Meaning
TLS	Protocol name (TLS)
AES_256_GCM	Encryption Algorithm (AES with 256-bit key in GCM mode)
SHA384	Hash Algorithm (SHA-384)

TLS 1.3 eliminates key exchange and authentication from the cipher suite name, as these are negotiated separately during the handshake. Unlike TLS 1.2, which required manual selection of cipher suites that included specific key exchange and authentication methods, TLS 1.3 ensures only secure algorithms are available by default.

This provides several security and performance improvements:

Prevents downgrade attacks → Attackers can no longer force the connection to fall back to a weaker key exchange or authentication method.
Simplified configuration → Reduces misconfigurations by eliminating manual selection of key exchange and authentication options.
Forward secrecy enforcement → TLS 1.3 requires ephemeral key exchange methods by default, making it impossible to decrypt past sessions even if the private key is compromised.
Reduced handshake latency → Simplified cipher suite negotiation enables faster and more efficient TLS handshakes.

Deprecated and insecure cipher suites↑

Over the years, numerous cipher suites have been found to be insecure due to weaknesses in their underlying cryptographic primitives. Despite being deprecated, many systems still support or offer these cipher suites, leaving them vulnerable to downgrade attacks, cryptanalysis, and padding oracle attacks.

Of those over 300 TLS 1.2 cipher suites, the majority rely on outdated and compromised cryptographic methods – such as DES (16), 3DES (20), RC4 (18), RC2 (3), SHA-1 (110), and MD5 (14), all of which have been broken or proven weak. These ciphers must be fully disabled to prevent potential exploits.

The following legacy cipher suites and algorithms are not considered secure and shouldn’t be used:

RC4-based cipher suites → Broken due to statistical biases that allow attackers to recover plaintext from encrypted traffic. RFC 7465 explicitly prohibits its use in TLS.
CBC-mode cipher suites → Vulnerable to padding oracle attacks, such as BEAST (CVE-2011-3389) and POODLE (CVE-2014-3566), which allow attackers to decrypt data by exploiting flaws in how block cipher padding is processed.
3DES (TLS_RSA_WITH_3DES_EDE_CBC_SHA) → Weak due to Sweet32 (CVE-2016-2183), which exploits the small 64-bit block size of 3DES, making it possible for attackers to recover plaintext after analyzing large amounts of encrypted traffic.
Export-grade RSA cipher suites → Originally designed to comply with 1990s-era cryptographic export restrictions, these weak ciphers can be forced onto modern connections via downgrade attacks, such as FREAK (CVE-2015-0204) and Logjam (CVE-2015-4000), compromising encryption strength.
MD5-based cipher suites → MD5 has been cryptographically broken for over a decade due to collision attacks, making it unsafe for message authentication or certificate signing. Despite this, 13 cipher suites in the IANA registry still use MD5.
SHA-1-based cipher suites → Once widely used for message authentication, SHA-1 has proven collision vulnerabilities that allow attackers to forge signatures and tamper with encrypted data. Despite its known weaknesses, 110 cipher suites still reference SHA-1.

Why these cipher suites are still a risk↑

Even though modern clients rarely choose these ciphers, offering them creates a major security risk. Attackers can exploit downgrade attacks to force weaker encryption, allowing them to:

Compromise session confidentiality by recovering plaintext from encrypted traffic.
Break authentication mechanisms by exploiting weak or broken hash functions like SHA-1 and MD5.
Modify encrypted data in transit, which can lead to man-in-the-middle (MITM) attacks.

Notable Downgrade Attack CVEs:

FREAK Attack (CVE-2015-0204) → Allowed attackers to force a weak export-grade RSA cipher, making TLS connections vulnerable to decryption.
Logjam Attack (CVE-2015-4000) → Exploited weak Diffie-Hellman key exchanges to downgrade TLS connections and decrypt traffic.
POODLE Attack (CVE-2014-3566) → Forced TLS connections to downgrade to SSL 3.0, which had weak CBC padding, allowing data decryption.
CVE-2021-38502 → Demonstrated weaknesses in TLS implementations where legacy cipher suites could be forced despite server preferences.
CVE-2019-14887 → Exploited misconfigurations in TLS servers to allow protocol downgrades, forcing clients to use weaker encryption.

Legacy support does not mean security. Many organizations still offer outdated ciphers simply because they haven’t been explicitly disabled, exposing them to preventable risks.

Mitigation
Administrators should take the following critical steps to eliminate legacy cipher risks:

Explicitly disable all cipher suites using RC4, CBC-mode, 3DES, export-grade RSA, MD5, and SHA-1 in server configurations.
Use only modern AEAD-based ciphers, such as AES-GCM or ChaCha20-Poly1305, which provide both encryption and integrity without relying on weak hash functions.
Regularly audit TLS configurations to ensure deprecated ciphers are fully removed, not just avoided.
Upgrade to TLS 1.3 where possible, as it removes support for all insecure ciphers by default, eliminating these risks entirely.

By enforcing strict TLS policies and proactively disabling legacy cryptographic mechanisms, organizations can eliminate weaknesses, strengthen encryption security, and prevent attackers from exploiting outdated configurations.

Security requirements and compliance↑

As cyber threats evolve, ensuring the security of encrypted communications has become a regulatory requirement, rather than just a best practice. Organizations, governments, and industry groups have established mandatory guidelines requiring TLS 1.2 or higher, aiming to phase out outdated cryptographic protocols that risk sensitive data exposure.

Mandatory TLS 1.2 or higher↑

With the growing number of vulnerabilities in older TLS versions, security organizations and regulatory bodies require the use of TLS 1.2 or later to maintain secure communication channels. TLS 1.0 and TLS 1.1, once the standard for encrypted internet traffic, are now considered obsolete and pose significant security risks. As a result, multiple organizations and standards bodies have issued mandatory deprecation policies, requiring systems to migrate to secure TLS versions, such as TLS 1.3.

Some of the most notable mandates include:

RFC 8996 (IETF) – The Internet Engineering Task Force (IETF) officially deprecated TLS 1.0 and TLS 1.1 in RFC 8996, recommending that all systems migrate to TLS 1.2 or TLS 1.3. The RFC explicitly states that these older versions shouldn’ not be used due to known cryptographic weaknesses.
NIST SP 800-52 Rev. 2 – The National Institute of Standards and Technology (NIST) requires U.S. federal systems to use TLS 1.2 or higher as part of their guidelines for secure communications. This mandate ensures government agencies and contractors phase out insecure encryption methods and adopt stronger cryptographic protocols.
NSA Guidance on TLS – The National Security Agency (NSA) issued official guidance (Eliminating Obsolete TLS) explicitly mandating the immediate discontinuation of TLS 1.0 and the phased removal of TLS 1.1. The NSA states that “TLS 1.1 and older provide inadequate protection for sensitive information” and requires that government and high-security networks enforce TLS 1.2 or higher, with a strong recommendation to migrate to TLS 1.3 wherever possible. This aligns with broader federal and industry-wide efforts to eliminate obsolete encryption protocols and enhance cryptographic security.
GSA SSL/TLS Implementation Guide – The General Services Administration (GSA) prohibited the use of TLS 1.0 as early as 2018, requiring federal agencies and government contractors to adopt strong encryption configurations. This policy ensures that systems handling government-related data meet modern security standards.

While TLS 1.2 remains widely supported, organizations should audit their configurations to ensure they aren’t offering deprecated cipher suites like 3DES and RC4, still present in some TLS 1.2 implementations. Simply supporting TLS 1.2 isn’t enough—it must be configured securely to prevent attackers from exploiting legacy weaknesses.

Older versions of TLS, as well as weak cipher suites, have been exploited in numerous real-world attacks, demonstrating the risks of failing to upgrade. The following vulnerabilities highlight why it is critical to fully disable and remove legacy TLS versions:

BEAST (CVE-2011-3389) – The Browser Exploit Against SSL/TLS (BEAST) attack exploits weaknesses in TLS 1.0’s CBC-mode encryption, allowing an attacker to perform a man-in-the-middle (MITM) attack and recover sensitive data from encrypted communications. This attack demonstrated why CBC-mode ciphers should no longer be used in modern TLS configurations.
POODLE (CVE-2014-3566) – The Padding Oracle On Downgraded Legacy Encryption (POODLE) attack forced TLS connections to downgrade to SSL 3.0, which had weak CBC padding mechanisms. Attackers could exploit these weaknesses to decrypt encrypted communications. While SSL 3.0 has been widely disabled, misconfigured servers that still offer it as a fallback remain vulnerable.
Sweet32 (CVE-2016-2183) – This attack targets 64-bit block ciphers, such as 3DES (Triple DES), which are still available in some TLS 1.2 configurations. Sweet32 exploits the small block size of 3DES, allowing attackers to recover plaintext data after collecting large amounts of encrypted traffic. This vulnerability reinforced the importance of disabling 3DES in TLS configurations.
RC4 Bias Attack (CVE-2013-2566, CVE-2015-2808) – RC4, once a widely used stream cipher in TLS, has been found to have statistical biases that allow attackers to decrypt encrypted traffic. The IETF officially prohibited RC4 in TLS (RFC 7465) due to these weaknesses. Despite this, some legacy systems still offer it as a fallback, leaving them vulnerable to downgrade attacks.

These vulnerabilities make it clear that simply “not using” a deprecated cipher suite isn’t enough—it must be removed from system configurations. Even if an outdated cipher suite or TLS version is rarely negotiated, its mere presence in the list of supported options exposes the server to downgrade attacks. Attackers can force weaker cipher suite negotiations through techniques such as protocol version rollback attacks, where they intercept and manipulate the TLS handshake to downgrade the connection to an older, vulnerable encryption method. This was exploited in attacks such as POODLE (CVE-2014-3566) and FREAK (CVE-2015-0204).

Why compliance matters↑

Failing to enforce modern TLS standards exposes sensitive data and leads to non-compliance with security regulations that require strong encryption. Many industries mandate TLS 1.2 or higher to protect financial transactions, healthcare records, cloud services, and user privacy.

To reduce risk, organizations should enforce at least TLS 1.2 and adopt TLS 1.3 where possible. Regular security audits and configuration reviews are essential to identify and remove outdated protocols and weak cipher suites, ensuring a secure and compliant encryption posture.