BoringSSL Adoption and Security Vulnerability Management

11/2/2022

This post details Cloudflare's non-impact from OpenSSL vulnerabilities CVE-2022-3602 and CVE-2022-3786 due to its use of BoringSSL. It explains the nature of the vulnerabilities (memory corruption, potential RCE in X.509 certificate verification) and the conditions for client and server impact. It also provides practical advice for users to identify and patch OpenSSL on their systems using `lsof` and package managers, and discusses the importance of memory safety.

12/6/2017

Migrated Cloudflare's edge SSL connection termination stack to BoringSSL. Enabled TLS 1.3 for all edge SSL traffic, consolidating it with TLS 1.2 and earlier. Introduced X25519 for key negotiation in TLS 1.2 and earlier connections. Enabled RSA-PSS for TLS 1.2 connections. Replaced custom patches for Keyless SSL, distributed session ID caches, and equal-preference cipher grouping with BoringSSL's built-in features. Developed a more reliable OCSP pipeline after OCSP was removed from BoringSSL. Added support for legacy ChaCha20-Poly1305 ciphers back into an internal BoringSSL fork. Optimized configuration to avoid repeated loading of CA trusted certificates from disk, addressing slow startup times due to BoringSSL's base64 decoder.

3/19/2015

This post details Cloudflare's response to multiple OpenSSL vulnerabilities announced on March 19, 2015. Cloudflare analyzed the vulnerabilities and determined they primarily posed a Denial of Service risk, capable of crashing proxy servers, rather than an information disclosure risk. Customer traffic and SSL keys remained protected. Cloudflare quickly tested the patched version of OpenSSL and began deploying it to its production environment. The post lists the specific CVEs addressed, including clientHello sigalgs DoS, RSA downgrades, multiblock pointer corruption, and various segmentation faults and NULL pointer dereferences.

3/4/2015

This post details Cloudflare's protection against the FREAK vulnerability by not supporting 'export grade' cryptography and upgrading to a non-vulnerable version of OpenSSL in January. It highlights the availability of their OpenSSL configuration and patches on GitHub and their proactive approach to disabling outdated protocols and ciphers while adopting secure ones.

6/5/2014

Cloudflare has patched all its systems against seven OpenSSL vulnerabilities, including the critical CVE-2014-0224 (CCS Injection), by applying the required patches. Customers are protected against these vulnerabilities.

4/28/2014

This post details the analysis of the Heartbleed vulnerability, specifically how it could leak private SSL keys. It explains the RSA algorithm, the role of prime numbers (p and q) in private keys, and how the Heartbleed vulnerability allowed attackers to read memory from vulnerable OpenSSL instances. The post investigates why prime numbers were seemingly easy to find in Heartbleed results by instrumenting OpenSSL and visualizing memory usage. It shows how OpenSSL creates temporary copies of primes during operations like Montgomery reduction, and how these copies, along with fragments of overwritten primes, could be exposed. The post also proposes specific patches to OpenSSL to improve memory cleansing for prime numbers, addressing issues in `bn_lib.c` and `bn_mont.c`, and suggests disabling Montgomery parameter caching to further mitigate the risk.

4/17/2014

This post details Cloudflare's response to the Heartbleed vulnerability, including the immediate patching of OpenSSL, the mass revocation and reissuance of all managed SSL certificates, and the hosting of a public challenge to identify private keys exposed by the vulnerability. It explains the technical mechanism by which Heartbleed leaks private keys, focusing on the exposure of intermediate RSA prime factors (p and q) in OpenSSL's memory buffers during private key operations. The post also outlines the winning techniques used to extract private keys, including primality testing and Coppersmith's Attack, and congratulates the challenge winners.

4/12/2014

This post details Cloudflare's immediate response to the Heartbleed vulnerability, including the decision to revoke the certificate for cloudflarechallenge.com. It analyzes and illustrates the varying behaviors of different browsers (Internet Explorer, Safari, Firefox, Chrome) when encountering a revoked certificate, highlighting the limitations of CRLSets in Chrome. The post also references Netcraft statistics showing a sharp increase in certificate revocations post-Heartbleed and encourages affected websites to revoke their certificates and rekey.

4/11/2014

This post details the results of the Heartbleed Challenge, where Cloudflare set up a vulnerable nginx server and challenged the community to steal its private key using the Heartbleed exploit. Two individuals, Fedor Indutny and Ilkka Mattila, successfully retrieved private keys, highlighting the danger of the vulnerability and the power of crowd-sourced security research.

4/11/2014

This post details the initial investigation into the Heartbleed vulnerability and its potential impact on private SSL keys. It explains the buffer over-read bug in OpenSSL, the mechanics of heap allocation and how it relates to data exposure, and the specific reasons why Cloudflare initially believed its systems were not vulnerable (due to NGINX's memory layout and the early loading of private keys). It also announces the creation of a public challenge to test this hypothesis, which ultimately proved Cloudflare's initial assessment incorrect.

4/7/2014

This post details Cloudflare's proactive response to the CVE-2014-0160 (Heartbleed) vulnerability in OpenSSL 1.0.1. Cloudflare fixed the vulnerability in its systems, which use OpenSSL for SSL/TLS connections, before it was publicly disclosed. All sites using Cloudflare for SSL were automatically protected. The post emphasizes the importance of responsible disclosure and encourages other server administrators to upgrade OpenSSL or recompile with specific flags.