TechPrufer
Get started
Cloudflare
Cloudflare logoCloudflare · Feature trail

BoringSSL Adoption and Security Vulnerability Management

11 posts · Feb 2013 – Nov 2022

What this trail covers

Cloudflare's security posture has been significantly bolstered by its strategic adoption of BoringSSL, a fork of OpenSSL maintained by Google. This decision has proven critical in mitigating the impact of high-risk vulnerabilities like CVE-2014-0160 (Heartbleed), which affected OpenSSL 1.0.1. The company's internal systems, which rely on BoringSSL, were not impacted, demonstrating the effectiveness of this architectural choice in isolating the organization from widespread third-party library vul

All Cloudflare trails
  1. Cloudflare is not affected by the OpenSSL vulnerabilities CVE-2022-3602 and CVE-2022-3786This post details the specific vulnerabilities CVE-2022-3602 and CVE-2022-3786 in OpenSSL 3.0.x, explaining their impact on clients and servers, and reiterating the importance of patching and memory safety. It highlights that Cloudflare is not affected due to its use of BoringSSL.
  2. Heartbleed RevisitedThis post revisits the Heartbleed vulnerability and details Cloudflare's advancements in TLS/SSL security over the past seven years. Key contributions include: 1. Enhanced key protection through Keyless SSL, Geo Key Manager, and Delegated Credentials, providing physical and logical separation of private keys. 2. Improvements in certificate revocation mechanisms, moving from unreliable CRLs and OCSP to supporting OCSP Must-staple for faster revocation and reduced risk exposure. 3. A comparison of 2014 security practices with current capabilities, highlighting the evolution towards shorter certificate lifetimes, 100% OCSP stapling, and advanced key management solutions.
  3. Make SSL boring againMigrated Cloudflare's edge SSL connection termination stack to BoringSSL, enabling support for TLS 1.3, X25519 for TLS 1.2, and RSA-PSS for TLS 1.2. Developed a more reliable OCSP stapling pipeline and added support for legacy ChaCha20-Poly1305 ciphers. Addressed performance issues with BoringSSL's base64 decoder by optimizing NGINX configuration.
  4. Yet Another Padding Oracle in OpenSSL CBC CiphersuitesThis post details a new padding oracle vulnerability (CVE-2016-2107) in OpenSSL's CBC mode decryption, specifically in the code that was intended to fix the Lucky13 vulnerability. The vulnerability arises from a subtle off-by-one error in constant-time code that checks padding length, allowing an attacker to craft messages that bypass HMAC checks. The author explains the mechanics of CBC padding oracles, constant-time programming techniques, and how this specific vulnerability can be exploited to decrypt data by aligning attacker-controlled bytes with ciphertext blocks and observing server responses.
  5. OpenSSL Security Advisory of 19 March 2015This post details Cloudflare's response to a batch of OpenSSL vulnerabilities released on March 19, 2015. The vulnerabilities primarily posed a Denial of Service risk, potentially crashing proxy servers, rather than an information disclosure risk. Customer traffic and SSL keys remained protected. Cloudflare quickly tested the patched OpenSSL versions and began deploying them to its production environment. The post lists specific CVEs addressed and encourages customers to upgrade their own OpenSSL installations, especially those using the 1.0.2 branch.
  7. No upgrade needed: CloudFlare sites already protected from FREAKThis post details Cloudflare's proactive stance against the FREAK vulnerability by highlighting that their sites were already protected due to not supporting 'export grade' cryptography and having upgraded to a non-vulnerable OpenSSL version in January. It emphasizes the availability of their OpenSSL configuration and patches on GitHub, and their ongoing commitment to disabling outdated protocols/ciphers and adopting secure ones like ChaCha-Poly, forward secrecy, and elliptic curves.
  8. SSLv3 Support Disabled By Default Due to POODLE VulnerabilityCloudflare disabled SSLv3 by default across its network in response to the POODLE vulnerability. This decision impacts older browsers and crawlers that default to SSLv3. The company tracked SSLv3 usage across its network, noting that most SSLv3 traffic was attack traffic or minor crawlers. Business and Enterprise customers can re-enable SSLv3 if necessary. Cloudflare is also studying mitigation strategies, including the use of BoringSSL's protection against SSL connection downgrades.
  9. New OpenSSL vulnerabilities: CloudFlare systems patchedCloudflare has applied the required patch to all its servers, protecting customers against CVE-2014-0224 (CCS Injection) and other announced OpenSSL vulnerabilities. The company advises all users of OpenSSL to upgrade to the newly released versions.
  10. The Web is World-Wide, or who still needs RC4?This post details Cloudflare's analysis of RC4 usage in TLS connections, identifying specific client types (older phones, browsers, software updates, transparent SSL proxies) and geographic regions still relying on it. It explains the RC4 algorithm and cipher suites, and highlights the need to continue supporting RC4 for a small percentage of users while encouraging updates to more secure protocols. The post also introduces 'How's My SSL' as a tool for users to check their browser's SSL configuration.
  11. Tracking our SSL configurationThis post details the evolution of Cloudflare's SSL configuration, driven by emerging security threats and vulnerabilities. It announces the creation of a public GitHub repository, 'sslconfig', to track these changes and their history. The post highlights specific vulnerabilities like Lucky 13, BEAST, and RC4 biases, and details Cloudflare's proactive measures, including modifying OpenSSL to prevent RC4 use for TLS 1.1+, introducing ECDSA, and continuously examining cipher suites for optimal security, such as utilizing Perfect Forward Secrecy.
  12. Searching for The Prime Suspect: How Heartbleed Leaked Private KeysThis post details the investigation into why the Heartbleed vulnerability made it easy to extract private RSA keys from vulnerable OpenSSL instances. It explains the RSA algorithm, Montgomery Reduction for performance, and how OpenSSL's memory management, specifically the handling of prime numbers (p and q) used in RSA keys, led to their exposure. The post includes instrumentation of OpenSSL to visualize memory usage and the presence of primes, and proposes patches to `bn_lib.c` and `bn_mont.c` to securely erase sensitive data from memory before freeing it, and to disable caching of Montgomery parameters. It highlights that while the core vulnerability was in OpenSSL, Cloudflare's internal systems using BoringSSL were not affected.
  13. The Heartbleed Aftermath: all CloudFlare certificates revoked and reissuedThis post details Cloudflare's response to the Heartbleed vulnerability, including the immediate patching of OpenSSL, the revocation and reissuance of all managed SSL certificates, and the launch of a public challenge to extract a private key. It explains the technical details of how Heartbleed leaks private keys by exploiting memory management in OpenSSL's RSA implementation, specifically the residual data in buffers used for computations. The post also details the RSA cryptosystem and the techniques used by challenge winners to extract private keys, such as searching for prime factors and applying Coppersmith's Attack. Finally, it provides recommendations for administrators to patch OpenSSL and reissue/revoke keys.
  14. Certificate Revocation and HeartbleedThis 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.
  15. The Results of the CloudFlare ChallengeThis post details the results of the Heartbleed Challenge, where Cloudflare set up a vulnerable OpenSSL server and challenged the community to steal its private key. Two individuals, Fedor Indutny and Ilkka Mattila, successfully retrieved the private key using the Heartbleed exploit. The post confirms that only the Heartbleed exploit was used and suggests that the key may have been available in uninitialized heap memory. It highlights the power of the crowd and the danger posed by the vulnerability.
  16. Answering the Critical Question: Can You Get Private SSL Keys Using Heartbleed?This post details the analysis of the Heartbleed vulnerability, a buffer over-read bug in OpenSSL. While initially speculated to expose private SSL keys, Cloudflare's extensive testing on their NGINX stack, which uses BoringSSL, found no evidence of private key exposure. This was attributed to the heap allocation strategy where private keys are loaded at low memory addresses, and the exploit only reads higher memory addresses. The post also describes the mechanics of the bug and the simple fix. Cloudflare initiated a proactive reissue and revocation of customer SSL keys as a precautionary measure.
  17. Staying ahead of OpenSSL vulnerabilitiesThis post details Cloudflare's proactive response to the Heartbleed vulnerability (CVE-2014-0160) in OpenSSL. Cloudflare had already fixed the vulnerability in its internal systems, which use BoringSSL (a fork of OpenSSL), before the public disclosure. 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 a specific flag.
  18. Killing RC4 (softly)This post details 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 to mitigate the BEAST attack. This addresses the trade-off between BEAST mitigation and RC4 vulnerability, allowing for better security by leveraging modern TLS versions and AES-GCM or AES-CBC.
  19. 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's default configuration is not vulnerable due to deprioritizing vulnerable ciphers. It recommends upgrading OpenSSL when a fix is released and prioritizing RC4 cipher suites. It provides recommended Apache and NGINX SSL cipher suite configurations.