TechPrufer
Get started
Cloudflare
Cloudflare logoCloudflare · Feature trail

Universal SSL Deployment

10 posts · Nov 2011 – Sep 2026

What this trail covers

Cloudflare's Universal SSL has evolved to include Automatic Key Exchange, an extension of Automatic SSL/TLS. This feature probes origin servers to determine their supported key agreement algorithms and prefers post-quantum hybrid algorithms like X25519MLKEM768 where supported. This reduces HelloRetryRequests, cutting connection handshake latency by over 150 ms at p90, and enables automatic post-quantum secure origin connections without manual configuration. This post extends this by introducing post-quantum (PQ) cryptography visibility tools into Cloudflare's Application Security and Logs products, allowing customers to inspect and graph the adoption of post-quantum TLS 1.3 encryption for live traffic from directly within Logpush, Log Explorer, and the HTTP Traffic Analytics dashboard. This provides granular, per-connection telemetry to audit post-quantum posture, assess compliance, and identify cryptographic gaps across domains.

All Cloudflare trails
  1. Is your domain using post-quantum encryption? Now you can see for yourselfThis post introduces new post-quantum (PQ) cryptography visibility tools within Cloudflare's Application Security and Logs products. Customers can now inspect and graph the adoption of post-quantum TLS 1.3 encryption for live traffic via Logpush, Log Explorer, and the HTTP Traffic Analytics dashboard. The feature surfaces the key exchange algorithm negotiated on every incoming request, providing per-connection telemetry. This allows customers to audit their post-quantum posture, assess compliance, and identify cryptographic gaps. The post details the hybrid ML-KEM approach in TLS 1.3, where ECDHE over X25519 and ML-KEM are executed together. It also highlights the distinction between visitor-to-Cloudflare connections (70% PQ adoption) and Cloudflare-to-origin connections (15% PQ adoption) as seen on Cloudflare Radar. New filtering terms for key exchange groups are available in the HTTP Traffic dashboard.
  2. Preventing quantum downgrade attacks against IPsecThis post details the development and implementation of a mitigation against quantum downgrade attacks on IPsec. It explains the vulnerability in IPsec's IKEv2 protocol that allows attackers to trick endpoints into using weaker classical cryptography by manipulating handshake messages. The post introduces an IETF extension that adds a downgrade protection mechanism to IPsec, ensuring that both parties support post-quantum cryptography. Cloudflare has implemented beta support for this extension in its IPsec products (WAN, Magic Transit) and encourages ecosystem adoption.
  3. Automatic Key Exchange: faster, post-quantum secure origin handshakes for 45 billion daily connections (and counting)Introduces Automatic Key Exchange, which replaces static key agreement algorithm guessing in TLS 1.3 client hellos with a per-origin measurement. This involves lightweight TLS handshake probes to identify supported algorithms, prioritizing post-quantum hybrids (X25519MLKEM768) and falling back to classical algorithms (X25519, P-256, P-384, P-521). The system dynamically tailors the initial keyshare to maximize post-quantum connections and minimize latency without risking outages. This reduces HelloRetryRequests from ~52% to 3.7% and improves connection handshake latency.
  4. Post-quantum authentication to origins is now supportedThis post introduces the addition of post-quantum authentication (ML-DSA) to Cloudflare's Authenticated Origin Pulls and Custom Origin Trust Store products. It details the engineering effort to integrate ML-DSA signatures for the Cloudflare-to-origin connection, enabling fully post-quantum secure mutually authenticated TLS connections. The post explains the configuration process, including generating ML-DSA certificates in the FIPS 204 seed-only format and uploading them via API for COTS and AOP. It also discusses the importance of avoiding downgrades to quantum-vulnerable authentication mechanisms and outlines future plans for WebPKI integration.
  5. Cloudflare One is the first SASE offering modern post-quantum encryption across the full platformThis post details the integration of post-quantum hybrid ML-KEM encryption into Cloudflare IPsec and the Cloudflare One Appliance, extending the platform's post-quantum capabilities beyond the Secure Web Gateway. It explains the rationale for prioritizing key establishment (ML-KEM) over digital signatures for IPsec due to interoperability challenges and the current threat landscape. The post also contrasts the IPsec journey with TLS's adoption of PQC and highlights the limitations of RFC 8784's PSK and QKD approaches, advocating for RFC 9370's hybrid key agreement.
  7. Keeping the Internet fast and secure- introducing Merkle Tree CertificatesIntroduces Merkle Tree Certificates (MTCs) as a proposal to redesign the WebPKI to accommodate large post-quantum cryptography signatures without performance degradation. MTCs aim to reduce TLS handshake overhead to 1 signature, 1 public key, and 1 Merkle tree inclusion proof by disseminating certificate information out-of-band. Announces an experimental deployment of MTCs with Chrome Security to test and learn from real-world usage.
  8. State of the post-quantum Internet in 2025This post provides an update on the state of post-quantum cryptography adoption on the internet, specifically noting that the majority of human-initiated traffic with Cloudflare is now protected by post-quantum encryption. It details advancements in quantum hardware and software, including Craig Gidney's optimizations that reduced the estimated qubit count required to break RSA-2048, effectively accelerating the projected Q-day. The post also discusses the discovery and subsequent refutation of Chen's algorithm, reinforcing the current reliance on lattice-based cryptography and the ongoing need for research into alternative cryptographic approaches. It highlights the proactive migration to post-quantum cryptography as a crucial step to counter harvest-now-decrypt-later threats.
  9. Automatically Secure: how we upgraded 6,000,000 domains by default to get ready for the Quantum FutureThis post details the results and methodology of Cloudflare's Automatic SSL/TLS system, which has automatically upgraded the security of over 6 million domains. It explains the TLS handshake process, the evolution of TLS protocols (TLS 1.0-1.3), and the challenges of securing the Edge <-> Origin TLS layer. The post describes how Automatic SSL/TLS works by scanning origin servers, comparing HTTP/HTTPS content, and checking TLS certificates to upgrade encryption modes (e.g., from Full to Full (Strict)) without user intervention. It highlights the low adoption rate of manual recommendations from the SSL/TLS Recommender as the motivation for building this automated system. The post also touches upon the preparation for post-quantum cryptography (PQC) with hybrid X25519 + MLKEM key agreement.
  10. HTTPS-only for Cloudflare APIs: shutting the door on cleartext trafficCloudflare is enforcing HTTPS-only connections for its API endpoints (api.cloudflare.com) by closing all cleartext HTTP ports. This is a preventative security measure to eliminate the risk of sensitive information, such as API tokens, being exposed in initial plaintext HTTP requests before redirection or rejection. The company also plans to offer an opt-in feature for customers to disable HTTP port traffic for their websites later in 2025. The implementation involved careful planning at scale, addressing challenges with legacy clients and the BSD Sockets API using Tubular.
  11. Conventional cryptography is under threat. Upgrade to post-quantum cryptography with Cloudflare Zero Trust.This post announces the first phase of end-to-end quantum readiness for Cloudflare's Zero Trust platform, enabling customers to protect corporate network traffic with post-quantum cryptography. It details how organizations can tunnel traffic through Cloudflare's Zero Trust platform to gain end-to-end quantum safety for clientless Access, WARP device client traffic, and Gateway TLS traffic. The technical details focus on the migration of TLS 1.3 key agreement mechanisms to ML-KEM, highlighting performance benefits and the 'harvest now, decrypt later' threat model. It also mentions the NIST timeline for deprecating RSA and ECC.
  12. A look at the latest post-quantum signature standardization candidatesThis post analyzes fourteen post-quantum signature schemes advanced to NIST's second round, evaluating their feasibility for TLS. It details the TLS handshake's signature requirements, comparing classical, existing post-quantum, and new candidate schemes based on public key size, signature size, signing time, and verification time. The analysis highlights the significant increase in data size and computational overhead compared to classical elliptic curve signatures, and discusses the trade-offs for different TLS components (online vs. offline signatures). It also touches upon the urgency of migrating key agreement to post-quantum cryptography versus the longer-term challenge of post-quantum signatures.
  13. How Cloudflare is helping domain owners with the upcoming Entrust CA distrust by Chrome and MozillaThis post announces the integration of SSL.com as a new certificate authority (CA) option within Cloudflare's Advanced Certificate Manager and SSL for SaaS products. This integration allows Cloudflare customers to automatically issue and renew SSL/TLS certificates from SSL.com, a CA trusted by major browsers, thereby mitigating the risk of disruption due to Chrome and Mozilla's upcoming distrust of Entrust certificates. The post details how customers can select SSL.com via the UI or API, specifies certificate validity periods (90 days by default, with options for 14, 30, or 1-year certificates for Enterprise), and explains the process for domain control validation (DCV), recommending DCV Delegation for automated management. It also highlights the benefits of migrating from manual Entrust certificate management to Cloudflare's managed pipeline.
  14. NIST’s first post-quantum standardsThis post announces the adoption of NIST's finalized post-quantum cryptography standards (ML-KEM, ML-DSA, SLH-DSA). It details the significance of these standards for resisting quantum computer attacks, Cloudflare's ongoing hybrid deployment of ML-KEM (currently protecting over 16% of human-generated requests), and the future migration path for post-quantum signatures. It also discusses the 'harvest now, decrypt later' threat model for key agreement and the more challenging migration for signatures due to the broader WebPKI ecosystem.
  15. Introducing Automatic SSL/TLS: securing and simplifying origin connectivityThis post announces the rollout of Automatic SSL/TLS, which leverages the existing SSL/TLS Recommender to automatically configure the optimal encryption mode for connections between Cloudflare and origin servers. The SSL/TLS Recommender probes origin servers to determine their capabilities and content similarity across different SSL/TLS modes (Off, Flexible, Full, Full (Strict), Strict) to recommend the most secure and risk-free configuration. This automates a previously manual process prone to error and downtime.
  16. Avoiding downtime: modern alternatives to outdated certificate pinning practicesThis post details the increasing problem of certificate pinning causing outages due to frequent certificate rotations by CAs and Cloudflare's own certificate migrations. It explains why certificate pinning is becoming obsolete by highlighting modern standards like shorter certificate lifetimes (moving towards 90-day validity), regular rotation of intermediate certificates (e.g., Let's Encrypt and Google Trust Services), and increased use of certificate transparency logs. The post advocates for adopting these modern, automated, and scalable practices over the manual and error-prone certificate pinning. It also mentions Cloudflare's Universal SSL pipeline and Advanced Certificate Manager as tools that support these modern practices.
  17. Introducing per hostname TLS settings — security fit to your needsIntroduced per-hostname TLS settings, allowing customers using Advanced Certificate Manager to configure minimum TLS version and supported cipher suites on individual hostnames. This feature supersedes zone-level settings and provides greater granularity for balancing security and accessibility across subdomains.
  18. Total TLS: one-click TLS for every hostname you haveIntroduced Total TLS, a one-click feature that automatically issues individual TLS certificates for every proxied subdomain of a customer's domain. This extends the coverage of Universal SSL beyond apex and wildcard certificates to include deeper subdomains. Also added warnings in the dashboard for proxied DNS records that do not have a TLS certificate covering them.
  19. Automatic (secure) transmission: taking the pain out of origin connection securityThis post details the evolution of automatically configuring the most secure connection possible between Cloudflare and customer origin servers. It explains the challenges of origin SSL/TLS configuration, the introduction of Cloudflare Origin CA, and the five SSL/TLS modes (Off, Flexible, Full, Full (strict), Strict). The core contribution is the introduction of automatic origin security upgrades using the SSL/TLS Recommender tool and the move from per-zone to per-origin SSL/TLS settings to maximize security for each origin.
  20. Introducing SSL/TLS RecommenderIntroduces the SSL/TLS Recommender tool, which guides users to stronger SSL/TLS configurations for the backend connection from Cloudflare to origin servers. Explains the different SSL/TLS encryption modes (Off, Flexible, Full, Full (strict), Strict (SSL-Only Origin Pull)) and their implications for security and functionality. Highlights the importance of securing the backend connection and the challenges of detecting TLS support on origin servers.
  21. Staging TLS Certificates: Make every deployment a safe deploymentIntroduced a staging environment for Enterprise customers to test custom uploaded TLS certificates before deploying them to production. This feature allows users to upload certificates to a staging network accessible via dedicated staging IPs, enabling them to verify certificate validity, subdomain coverage, and the correctness of certificate pinning configurations. The staging environment also supports disabling and re-enabling certificates, facilitating quick rollbacks or further testing.
  22. Keyless SSL now supports FIPS 140-2 L3 hardware security module (HSM) offerings from all major cloud providersThis post announces the integration of Keyless SSL with FIPS 140-2 Level 3 validated hardware security modules (HSMs) from major cloud providers (AWS, Google Cloud, IBM Cloud, Microsoft Azure) and other PKCS#11 compliant HSMs. It details the process of provisioning and activating cloud-hosted HSMs, specifically providing an end-to-end example with Microsoft Azure Managed HSM. The post explains how to configure the open-source gokeyless daemon to interface with these HSMs for TLS handshakes, allowing customers to maintain custody of their private keys while utilizing Cloudflare's edge security. This expands Keyless SSL's capabilities beyond on-premise HSMs and self-managed gokeyless servers.
  23. Going Proactive on Security: Driving Encryption Adoption IntelligentlyIntroduced HelperBot, an internal AI system using NLP and automated tests to triage SSL/HTTPS support tickets and present debugging information to agents. Developed the SSL Test Tool (HelperBot-External) to expose a subset of these diagnostic capabilities to external users, helping them identify and fix common HTTPS misconfigurations. This initiative aims to proactively drive encryption adoption by simplifying the process for customers and reducing common configuration errors.
  24. Today, Chrome Takes Another Step Forward in Addressing the Design Flaw That is an Unencrypted WebThis post details the Chrome 68 update which flags all non-secure HTTP connections as 'Not Secure'. It discusses the historical context of HTTPS adoption, the ongoing efforts to make HTTPS the default, and the technical implications for website owners. It highlights that while many sites are adopting HTTPS, there are still risks associated with unencrypted connections, even for static sites. Cloudflare's role in simplifying HTTPS adoption and offering a free SSL test tool is also mentioned.
  25. T-25 days until Chrome starts flagging HTTP sites as "Not Secure"This post details the upcoming change in Chrome's security indicators for HTTP sites and advocates for the adoption of HTTPS. It explains that HTTPS is no longer difficult to deploy, even for SaaS providers, and debunks the myth that it is slow. Cloudflare's services, including automatic certificate management and edge deployment, are highlighted as solutions to avoid the "Not Secure" flag. It also mentions the "Always use HTTPS" toggle and Automatic HTTPS Rewrites as features to help users transition.
  26. You get TLS 1.3! You get TLS 1.3! Everyone gets TLS 1.3!This post announces the general availability and default enablement of TLS 1.3 for Cloudflare customers. It details the technical challenges and solutions implemented to ensure compatibility with non-compliant middleboxes, including reintroducing the ChangeCipherSpec message and using the 'session_id' field in ClientHello to mimic previous TLS versions. It also discusses the impact of these changes on browser adoption and provides adoption metrics showing a significant increase in TLS 1.3 connections to Cloudflare websites.
  27. HTTPS or bust: Chrome’s plan to label sites as "Not Secure"This post announces Chrome 68's plan to label all HTTP sites as "not secure" starting July 2018. It details the historical milestones leading to this change, including Google's ranking signal for HTTPS, Cloudflare's Universal SSL, and various browser vendor initiatives. It predicts Google will remove the lock icon entirely in Chrome 72 (Jan 2019) when HTTPS usage is expected to exceed 85%. The post emphasizes that HTTPS is now fast, simple, and cost-effective, removing excuses for not using it.
  28. How "expensive" is crypto anyway?This post provides a detailed profiling of cryptographic algorithm performance in a production TLS deployment at Cloudflare's Frankfurt data center. It quantifies the CPU usage of BoringSSL (1.8% of total CPU time) and breaks down the consumption by cipher suites (AES-128-GCM, ChaCha20-Poly1305, AES-128-CBC-SHA1), public key operations (RSA, ECDHE, ECDSA), and hash functions (SHA1, SHA2). It highlights the relative cost of RSA and P256 operations and discusses the trend towards more efficient algorithms. The post also briefly mentions the future challenge of post-quantum cryptography.
  29. Performing & Preventing SSL Stripping: A Plain-English PrimerThis post explains SSL stripping attacks, how they work by intercepting HTTP traffic and replacing HTTPS links with HTTP, and the role of SSLStrip. It then introduces HTTP Strict Transport Security (HSTS) as a defense mechanism, detailing how it works via the `Strict-Transport-Security` header. The post also discusses the limitations of HSTS, such as the need for an initial connection and the possibility of bypassing it by manipulating system time, and introduces HSTS Preloading as a solution to hardcode HTTPS-only connections for specific sites.
  30. High-reliability OCSP stapling and why it mattersThis post details the implementation of high-reliability OCSP stapling, a significant enhancement to Cloudflare's HTTPS service. It addresses the challenges of certificate revocation checking by moving the responsibility from the browser to Cloudflare's edge servers. The new architecture redesigns the OCSP stapling infrastructure to be more robust and reliable, ensuring that valid OCSP responses are served for all connections where the certificate authority has enabled OCSP. This improves connection times by up to 30% and strengthens security by providing a more reliable proof of non-revocation.
  31. Introducing Dedicated SSL CertificatesIntroduced Dedicated SSL Certificates and Dedicated SSL Certificates with Custom Hostnames. These new products offer non-shared, customizable certificates issued on-demand with a new private key generated exclusively for a domain. They address customer requests for branded certificates, control over subdomains (including multiple levels of wildcards), and granular control over SSL/TLS features. The ordering process is integrated into the Cloudflare Dashboard, taking minutes to provision and distribute to the global network. Priority order for certificate serving is defined: Uploaded Certificates > Dedicated Certificates with Custom Hostnames > Dedicated Certificates > Universal Certificates.
  32. TLS Certificate Optimization: The Technical Details behind "No Browser Left Behind"This post details the technical logic Cloudflare uses to select the optimal TLS certificate (SHA-1 RSA, SHA-2 RSA, or SHA-2 ECDSA) to present to a client based on its capabilities, as communicated in the ClientHello message. It explains the TLS handshake steps relevant to certificate selection and validation, and outlines a decision tree that prioritizes compatibility with legacy browsers while serving modern certificates to capable clients. The logic is specific to paid plans, with free plans always receiving SHA-256/ECDSA.
  33. Logjam: the latest TLS vulnerability explainedThis post details the Logjam vulnerability, a downgrade attack against TLS that exploits EXPORT cryptography to force weak 512-bit Diffie-Hellman parameters. Cloudflare customers are protected because Cloudflare does not support non-EC Diffie-Hellman cipher suites or EXPORT-grade cryptography. The post explains how Diffie-Hellman works, the concept of Forward Secrecy, and how the Logjam attack leverages weak parameters and the lack of server signing of chosen parameters. It highlights that both client and server must be vulnerable for the attack to succeed and notes that modern browsers are moving to restrict DH parameter sizes. Cloudflare's network uses ECDHE for 94% of TLS connections, providing Forward Secrecy.
  34. Go crypto: bridging the performance gapThis post details the development of assembly implementations for AES-GCM and Elliptic Curve operations (P256) in Go, specifically for the amd64 architecture, to bridge the performance gap with state-of-the-art libraries like OpenSSL. These implementations leverage AES and CLMUL NI instructions to achieve significant speedups (up to 23.4X for AES-128-GCM and over 18X for P256 operations) over the standard Go 1.4.2 library. The implementations are constant-time and side-channel protected. The post also includes minor improvements to Go's RSA implementation. A fork of Go with these improvements is available for use.
  35. Do the ChaCha: better mobile performance with cryptographyThis post announces the addition of ChaCha20-Poly1305 cipher suites to Cloudflare's supported TLS configurations. This provides a secure and performant stream cipher option for mobile devices and older hardware that lack AES hardware acceleration, improving connection establishment times and reducing battery consumption. The post details the cryptographic strength of ChaCha20 and Poly1305, their AEAD construction, and performance benchmarks comparing them to AES-GCM on mobile devices. Cloudflare intelligently selects between AES-GCM and ChaCha20-Poly1305 based on client capabilities.
  36. SSL Week Means Less Weak SSLThis post announces the initiation of 'SSL Week' at Cloudflare, focusing on improving encryption on the Internet. Key technical announcements and initiatives include: 1) Making it easy and free to ensure the connection from Cloudflare back to the origin is secure. 2) Rolling out a way to cryptographically ensure the connection to the origin is coming from Cloudflare's network. 3) Adding support for a fast, new cipher suite that performs well on mobile devices. 4) Deprecating support for an older, less secure cipher suite.
  37. Flexible SSL & Wordpress: Fixing “Mixed Content” ErrorsThis post introduces a solution for 'Mixed Content' errors in WordPress sites using Cloudflare's Flexible SSL. It explains that Flexible SSL creates an HTTPS connection between the visitor and Cloudflare, but an HTTP connection between Cloudflare and the origin server. When a webpage is loaded over HTTPS, browsers expect all assets to also be loaded over HTTPS. The Cloudflare WordPress plugin has been updated to rewrite asset links from `http://` to a relative protocol `//`, ensuring assets are loaded over the same protocol as the main page. It also recommends a page rule to redirect HTTP traffic to HTTPS. Limitations of protocol rewriting are noted, particularly for assets loaded via JavaScript and for sites handling sensitive information, where Full SSL is recommended.
  38. CloudFlare in 2014: Bigger, Faster, SecurerThis post announces the introduction of Universal SSL in September 2014, fulfilling a promise made at the start of the year to make SSL free for everyone. It also details other technical achievements in 2014, including network expansion (Chile, Spain, Italy, Brazil, Colombia, Peru, South Africa), security enhancements (Strict SSL, Keyless SSL, patching OpenSSL vulnerabilities, disabling SSLv3 due to POODLE, upgrading SHA-1 certificates), protocol support (SPDY/3.1, WebSockets, CNAME flattening), and DDoS mitigation (400Gbps NTP amplification attack).
  39. CloudFlare and SHA-1 CertificatesThis post details Cloudflare's immediate response to upcoming SHA-1 deprecation by Chrome and Firefox. For paid customers, Cloudflare reissued certificates with SHA-1 signatures expiring before 2016 to maintain compatibility with older browsers like IE on Windows XP. Free customers' Universal SSL certificates, which are SHA-2 by default, are unaffected. The post outlines the future plan to roll out SNI certificates to paid customers, offering modern security features while retaining SHA-1 as a fallback for legacy browser support.
  40. The little extra that comes with Universal SSLThis post announces the general availability of SPDY 3.1 for all Cloudflare users, enabled by the Universal SSL initiative. It highlights that SPDY requires SSL/HTTPS, and by providing free SSL certificates, Cloudflare is enabling SPDY for all its customers, leading to performance improvements through features like multiplexing and prioritized delivery.
  41. Universal SSL: How It ScalesThis post details how Cloudflare scaled Universal SSL by leveraging modern hardware with AES-NI and CLMUL instructions for efficient data encryption, and ECDSA/ECDHE with elliptic curve cryptography (P-256) for faster TLS handshakes. It also explains the use of session resumption (tickets and IDs) for returning visitors and lazy loading of certificates in nginx to handle millions of HTTPS sites without performance bottlenecks.
  42. Universal SSL: Be just a bit more patientThis post details the challenges and expected timeline for the initial large-scale deployment of Universal SSL certificates to millions of websites. It explains that the process is taking longer than initially anticipated due to the sheer volume of websites and new sign-ups, with an updated expected completion time of 48 hours from the publication date. It also describes the certificate mismatch errors users might encounter during provisioning and how the login alert has been updated to track provisioning progress.
  43. Origin Server Connection Security with Universal SSLThis post introduces the concept of Full and Strict SSL modes for Cloudflare sites, building upon the recent enablement of Universal SSL. It provides guidance on how users can achieve these modes by installing certificates on their origin servers. Option 1 details using self-signed certificates (generated via CFSSL or OpenSSL) for 'Full SSL', which encrypts traffic between Cloudflare and the origin but lacks origin authentication. Option 2 describes obtaining certificates from trusted CAs (like StartSSL) for 'Strict SSL', which provides both encryption and authentication. A preview of the upcoming Origin CA service is also mentioned, which will offer faster certificate issuance for Cloudflare-trusted certificates.
  44. Introducing Universal SSLThis post announces the initial rollout of Universal SSL, enabling SSL connections for all Cloudflare customers, including free tier users. It details the technical challenges of CPU load and IPv4 exhaustion, and how they were overcome using ECDSA certificates and Server Name Indication (SNI). The post also highlights the benefits of SPDY protocol support and encourages modern browser adoption.
  45. Google Now Factoring HTTPS Support Into Ranking; CloudFlare On Track to Make it Free and EasyIntroduced 'lazy loading' of SSL certificates, allowing certificates to be dynamically retrieved on demand rather than pre-loaded into server memory. This technical change addresses a major hurdle in making SSL available to all Cloudflare customers, including free tier users, by enabling continued traffic shifting and network management even with millions of domains. The post announces the upcoming rollout of free SSL for all customers by mid-October.
  46. ECDSA: The digital signature algorithm of a better internetThis post introduces support for custom ECDSA certificates for Cloudflare business customers. It explains the technical benefits of ECDSA over RSA for TLS connections, including smaller key sizes, faster cryptographic operations (9.5x faster on Cloudflare's servers), and improved scalability. The post details how ECDSA works, its use in other applications like Bitcoin and iOS security, and the performance gains achieved by using ECDSA certificates for TLS handshakes. Cloudflare's blog itself is now served using an ECDSA certificate.
  47. Introducing Strict SSL: Protecting Against a On-Path Attack on Origin TrafficIntroduced 'Full SSL (Strict)' mode for TLS connections between Cloudflare and origin servers. This mode adds validation of the origin server's certificate against Cloudflare's trusted Certificate Authority list, preventing on-path attacks. This feature is available to all paying customers. Cloudflare has also upstreamed its origin certificate validation and SNI support changes to nginx.
  48. Staying on top of TLS attacksThis post details the evolution of Cloudflare's TLS cipher suite configurations in response to newly discovered attacks against RC4 and AES-CBC modes. It explains the negotiation of ciphersuites, the importance of forward secrecy with ECDHE, and the specific vulnerabilities of RC4 (keystream biases) and AES-CBC (Lucky-13, BEAST). Cloudflare's configuration is updated to prioritize ECDHE ciphers and prepare for wider adoption of TLS 1.2 and AES-GCM, while acknowledging the current reliance on RC4 and AES-CBC due to browser support limitations.
  49. CloudFlare, PRISM, and Securing SSL CiphersThis post discusses the security implications of SSL cipher suites in the context of government surveillance programs like PRISM. It explains how older, weaker SSL ciphers (like 1024-bit RSA) are vulnerable to brute-force attacks, allowing adversaries to decrypt recorded traffic. The post advocates for the use of stronger, more modern cipher suites such as ECDHE with 2048-bit keys, which provide forward secrecy and significantly increase the computational difficulty of breaking encryption. Cloudflare highlights its own adoption of these best practices, issuing 2048-bit keys by default and preferring ECDHE cipher suites for its customers.
  50. What We Just Did to Make SSL Even FasterIntroduced an automated SSL bundler that intelligently optimizes certificate chains by removing unnecessary intermediate and root certificates. Developed a directory of common intermediate certificates and a system to build the shortest, most trusted chain from uploaded certificates to browser-trusted roots. This process automates manual optimizations for performance and security, improving SSL handshake speed.
  51. CloudFlare Works with GlobalSign to Make SSL Faster Across the WebThis post details a partnership with GlobalSign to serve their CRL and OCSP requests from Cloudflare's global cache. This initiative reduces the latency of SSL certificate revocation checks from an average of 500ms to under 100ms, saving approximately 1.5 years of user time daily across the web. It also highlights the availability of these accelerated checks over IPv6.
  52. OCSP Stapling: How CloudFlare Just Made SSL 30% FasterThis post introduces the implementation of OCSP Stapling across Cloudflare's network. It explains the performance overhead of traditional OCSP/CRL checks during SSL handshakes, which can account for over 30% of the HTTPS overhead. OCSP Stapling is presented as a solution where the OCSP response is 'stapled' to the initial SSL handshake, eliminating the need for the browser to directly contact the Certificate Authority. Cloudflare's network-wide deployment of this feature is highlighted as a significant performance improvement for all HTTPS connections served through their platform.
  53. Easiest SSL Ever, Now Included Automatically with Every Paid PlanThis post announces the automatic inclusion of SSL for all paid Cloudflare accounts at no additional cost, removing previous per-subdomain charges and manual configuration steps. It introduces a 'flexible' SSL mode that encrypts traffic from visitors to Cloudflare's network, enabling SSL even for services that don't support certificate installation on the origin server. The default mode is intelligently set to flexible or end-to-end based on backend server support, with options to override or disable it.