TLS Cryptographic Modes and Vulnerabilities

4/21/2017

This 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.

5/4/2016

This 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/18/2016

This 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.

2/12/2016

This 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.

2/11/2016

This 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`.

5/21/2015

This 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.

2/24/2015

This 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.

2/23/2015

This post details the complete disabling of the RC4 encryption algorithm for all SSL/TLS connections to Cloudflare sites. It follows previous steps of disabling RC4 for TLS 1.1+ and deprecating it by moving it to the lowest priority. The post analyzes the remaining usage of RC4, identifying old mobile phones, Windows XP users, and SSL-intercepting proxy software as the primary sources. It explains the decision to disable RC4 due to its inherent insecurity and the availability of more secure alternatives, despite a small percentage of remaining users.

2/23/2015

This 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.

10/14/2014

This 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.

5/7/2014

This post details Cloudflare's decision to deprecate RC4 as a preferred cipher suite for TLS connections, moving towards AES-CBC and AES-GCM. It explains the historical context of RC4's rise due to the BEAST attack and the subsequent discovery of RC4's own weaknesses. The post outlines the technical implementation of lowering RC4's priority and the observed impact on connection statistics, highlighting the minimal remaining usage and the rationale for prioritizing long-term security over compatibility with outdated clients.

5/3/2014

This 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.

1/29/2014

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.

7/12/2013

This 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.

2/4/2013

This 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.

6/2/2012

This 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.