TechPrufer
Get started
Cloudflare
Cloudflare logoCloudflare · Feature trail

TLS Cryptographic Modes and Vulnerabilities

16 posts · Jun 2012 – Apr 2017

What this trail covers

Cloudflare's TLS cryptographic modes and vulnerabilities management has evolved to proactively address emerging threats and improve security. This includes modifying OpenSSL to prevent the use of RC4 for TLS 1.1 and above, introducing ECDSA, and continuously evaluating cipher suites to ensure optimal security for customers, such as by utilizing Perfect Forward Secrecy. The company maintains a public GitHub repository (sslconfig) to track the history and current state of its SSL configuration, and has now deprecated RC4 as a preferred cipher suite, prioritizing AES-based ciphers for improved long-term security and to mitigate risks associated with RC4's known weaknesses and potential future breaks.

All Cloudflare trails
  1. AES-CBC is going the way of the dodoThis post details the decline of AES-CBC cipher suites on Cloudflare's edge network, with their share dropping below ChaCha20-Poly1305 and approaching 10%. It also notes the surpassing of RSA by ECDSA for digital signatures and the near-ubiquitous adoption of Perfect Forward Secrecy (PFS). The internal breakdown of AES-CBC connections shows a prevalence of ECDHE-RSA or RSA key exchange, indicating older clients.
  2. NCC Group's Cryptography Services audits our Go TLS 1.3 stackThis post details the development and audit of Cloudflare's custom Go implementation of TLS 1.3. It highlights the use of the Go standard library's `crypto/tls` as a base, the engagement of NCC Group for a security audit, and the codebase's availability on GitHub. The implementation prioritizes modern cryptographic algorithms and includes defenses against downgrade attacks. The goal is to upstream these changes to the Go project.
  3. Yet Another Padding Oracle in OpenSSL CBC CiphersuitesThis post details a specific padding oracle vulnerability (CVE-2016-2107) in OpenSSL's CBC mode decryption, which was a fix for the Lucky13 attack. It explains how the vulnerability arises from constant-time code that still leaks information about padding length, allowing an attacker to craft messages that bypass HMAC and padding checks. The post provides a technical deep dive into the 'off by 20' flaw, demonstrating how manipulating padding length can cause the HMAC mask to fall out of bounds, leading to a successful MAC check. It also outlines how this capability can be used as an oracle for decrypting data, particularly by aligning unknown bytes with controlled plaintext sequences.
  4. IETF Hackathon: Getting TLS 1.3 working in the browserThis post details the work done at the IETF Hackathon to integrate and test TLS 1.3 features, specifically focusing on browser-to-server interoperability between Firefox and Cloudflare's test site. It highlights the successful implementation of PSK-based session resumption and the near-completion of 0-RTT functionality, contributing to the real-world testing and feedback necessary for TLS 1.3 standardization.
  5. Staying afloat: the DROWN Attack and CloudFlareThis post details Cloudflare's automatic protection against the DROWN attack by not enabling SSLv2 on its servers and proactively testing customer origin servers. It also highlights the company's public SSL configuration repository and its support for TLS 1.0, 1.1, and 1.2.
  7. Padding oracles and the decline of CBC-mode cipher suitesThis post explains the mechanics of block ciphers (ECB vs. CBC), the TLS record format, and the padding oracle attack. It details how the unauthenticated padding in CBC mode, combined with different server error responses or timing differences, allows attackers to extract plaintext data. It also presents data showing the increasing adoption of safer cipher modes like AEAD.
  8. Change the (S)Channel! Deconstructing the Microsoft TLS Session Resumption bugThis post details a specific breakdown in Microsoft's SChannel implementation when handling TLS session ticket renewals. Cloudflare's optimized TLS session ticket handling, which involves frequent key rotation and re-encryption of tickets during abbreviated handshakes, caused SChannel to either abort connections or downgrade from TLS 1.2 to TLS 1.0. This highlights a bug in SChannel's handling of the `NewSessionTicket` message when it's included in the abbreviated handshake after the `ServerHello`.
  9. Logjam: the latest TLS vulnerability explainedThis post details the Logjam vulnerability, which exploits weak Diffie-Hellman (DH) parameters in TLS, particularly through downgrade attacks using EXPORT cryptography. It explains how the attack works by forcing clients and servers to use small, breakable DH parameters (512-bit) that can be precomputed and broken by attackers. The post highlights that Cloudflare customers are not affected because Cloudflare does not support non-EC Diffie-Hellman ciphersuites or EXPORT-grade cryptography, and ensures sufficient parameter sizes for DHE when used. It also discusses the reuse of DH parameters and the vulnerability of servers that use small parameters even for non-EXPORT DHE. The post emphasizes the importance of using strong DH parameters (at least 1024-bit, preferably 2048-bit) and the role of modern browsers in restricting DH parameter sizes to mitigate such attacks.
  10. TLS Session Resumption: Full-speed and SecureThis post details Cloudflare's implementation of TLS session resumption using both Session IDs and Session Tickets to improve HTTPS performance. For Session IDs, it describes using a memcached cluster within each PoP to share encrypted session data across hosts, leveraging OpenResty and asynchronous calls. For Session Tickets, it explains the server-side encryption of session keys, hourly rotation, secure global distribution without disk storage, and a mechanism to handle clock synchronization issues by pre-generating keys. Performance improvements are quantified, showing session resumption costs less than 50% of a full TLS handshake.
  11. End of the road for RC4This post details the complete disabling of the RC4 encryption algorithm for all SSL/TLS connections to Cloudflare sites. This action was taken due to the availability of more secure algorithms and a significant decline in RC4 usage, with remaining users primarily on older mobile phones, Windows XP, or using SSL-intercepting proxy software. The post also references previous efforts to deprecate RC4 and highlights the ongoing academic research into RC4 attacks.
  12. SSL Week Means Less Weak SSLThis post announces the start of 'SSL Week' and outlines Cloudflare's ongoing commitment to improving encryption on the internet. Key initiatives include making origin connections secure and cryptographically verifiable, introducing support for a new, fast cipher suite (likely AEAD), and deprecating an older, less trusted cipher suite. This signifies an evolution in their TLS cryptographic modes and vulnerability management.
  13. SSLv3 Support Disabled By Default Due to POODLE VulnerabilityThis post details the disabling of SSLv3 by default across Cloudflare's network due to the POODLE vulnerability. It quantifies SSLv3 usage across the network, identifies affected user agents (primarily older browsers and some crawlers), and outlines an override option for Business and Enterprise customers. It also discusses the potential mitigation strategy of implementing Fallback SCSV, inspired by BoringSSL, to prevent forced downgrades to SSLv3.
  14. Killing RC4: The Long GoodbyeThis post details Cloudflare's decision to deprecate RC4 as a preferred cipher suite for HTTPS connections, prioritizing AES-based cipher suites (AES-CBC and AES-GCM) for improved long-term security. It explains the historical context of RC4's rise due to the BEAST attack, the subsequent introduction of client-side mitigations and TLS 1.2, and the mounting evidence of RC4's inherent weaknesses. The post outlines the impact of this change on traffic patterns, showing a significant reduction in RC4 usage, and provides updated recommended cipher suite lists for different client compatibility needs.
  15. Tracking our SSL configurationThis post introduces the 'sslconfig' GitHub repository to track Cloudflare's SSL configuration history and current state, providing a centralized and transparent way for users to stay updated. It highlights past security incidents (Lucky 13, BEAST, RC4 biases) that drove configuration changes, including preventing RC4 use in TLS 1.1+, introducing ECDSA, and the ongoing examination of cipher suites for Perfect Forward Secrecy.
  16. Killing RC4 (softly)This post introduces a patch for OpenSSL that disables RC4-based cipher suites for connections using TLS v1.1 and above, while retaining them for TLS v1.0. This addresses the vulnerability of RC4 attacks while still mitigating the BEAST attack for older TLS versions. The patch modifies the `ssl/s3_lib.c` file to conditionally skip RC4 cipher suites when the TLS version is 1.1 or greater. This change aims to improve the security posture of websites by aligning with SSL Labs' updated testing which penalizes the use of RC4 on TLS v1.1 and v1.2 connections.
  17. Staying on top of TLS attacksThis post details Cloudflare's response to a new attack against the RC4 cipher used in TLS connections. It explains TLS ciphersuites, the negotiation process, and the importance of forward secrecy provided by ECDHE. The post outlines Cloudflare's nginx configuration for SSL protocols and ciphers, prioritizing ECDHE and AES128-GCM-SHA256 (though not widely supported at the time). It discusses the vulnerabilities of RC4 (keystream biases) and AES in CBC mode (Lucky-13, BEAST), and Cloudflare's strategy to mitigate these risks by prioritizing RC4 over CBC modes when TLSv1.2 was not widely adopted, and now addressing the RC4 vulnerability.
  18. New "Lucky Thirteen" SSL Vulnerabilities: CloudFlare Users ProtectedThis post details the 'Lucky Thirteen' SSL vulnerability, a timing attack affecting TLS 1.1/1.2. It explains that Cloudflare users are protected by default due to deprioritizing vulnerable ciphers. It also provides recommended SSL configurations for Apache and NGINX to mitigate the vulnerability, prioritizing RC4 cipher and specific protocols.
  19. Taming BEAST: Faster, Safer SSL now on CloudFlareThis post details Cloudflare's implementation of TLS 1.1 and 1.2, and prioritization of RC4 cipher suites to mitigate the BEAST SSL attack. It also covers the addition of stronger cipher suites and removal of weaker ones, leading to a 30% improvement in SSL performance and an 'A' score from SSLLabs.