TechPrufer
Get started
Cloudflare
Cloudflare logoCloudflare · Feature trail

Protocol Deprecation and Evolution

30 posts · Jun 2012 – Oct 2025

What this trail covers

Cloudflare's protocol evolution capabilities have been enhanced by addressing a vulnerability in Mutual TLS session resumption. The issue, tracked as CVE-2025-23419, allowed a client with a valid mTLS certificate for one zone to resume a TLS session with another zone without re-authentication. Cloudflare mitigated this by disabling TLS session resumption for all customers with mTLS enabled. The company is exploring ways to reintroduce performance benefits while maintaining security and is providing customers with tools like Transform Rules and Logs Custom Fields to further harden their mTLS configurations and detect future issues. This evolution also includes the ability to pass detailed client certificate metadata to origins and use this information in WAF custom rules for enhanced security checks.

All Cloudflare trails
  1. Go and enhance your calm- demolishing an HTTP:2 interop problemThis post details a specific misuse of the HTTP/2 protocol in Go's standard library that can lead to PING flood attacks and trigger Cloudflare's defenses, resulting in ENHANCE_YOUR_CALM errors. The solution involves ensuring response bodies are fully read before closing connections.
  2. Resolving a Mutual TLS session resumption vulnerabilityThis post details a specific vulnerability (CVE-2025-23419) in Cloudflare's Mutual TLS (mTLS) implementation related to TLS session resumption. The vulnerability arose from an incorrect use of BoringSSL's API for partitioning session caches, allowing a client certificate validated for one zone to be used to resume a session with another zone without re-authentication. The post explains the background of mTLS and session resumption, the technical details of the exploit, and the mitigation strategy of disabling session resumption for mTLS connections. It also outlines further hardening steps for customers, including the use of Transform Rules to add client certificate metadata to requests and logs, and the application of WAF custom rules to check Issuer SKI for additional security.
  3. Connection coalescing with ORIGIN Frames: fewer DNS queries, fewer connectionsThis post details the implementation and benefits of connection coalescing using HTTP/2 and HTTP/3 ORIGIN Frames. It explains how the ORIGIN Frame standard allows servers to signal to clients which hostnames are available on an established TLS connection, enabling the reuse of connections for different hostnames. This reduces the number of DNS queries and TCP/QUIC connections required to load web pages, improving performance and reducing client metadata exposure. The post contrasts this with IP-based coalescing and highlights the advantages of the ORIGIN Frame approach.
  4. Cloudflare is deprecating RailgunThis post announces the deprecation of the Railgun product, which provided delta compression for dynamically generated content. It explains the rationale for deprecation, citing the product's stagnation, the availability of superior alternatives, and the maintenance burden. It recommends Cloudflare Tunnel for persistent, secure connections without public IPs, Argo Smart Routing and Cloudflare Network Interconnect for performance improvements, and Bandwidth Alliance/R2 for reducing egress costs. The deprecation timeline is set for January 31, 2024.
  5. Early Hints update: How Cloudflare, Google, and Shopify are working together to build a faster Internet for everyoneThis post details the evolution and impact of Early Hints, a feature leveraging HTTP 103, which sends instructions to the browser to begin loading readily-available resources while the server finishes compiling the full response. It highlights the collaboration with Google (Chrome) and Shopify, the performance improvements observed (up to 30% in LCP), and the lab testing conducted using WebPageTest across various network conditions. The post also announces Chrome's full support for Early Hints in version 103 and shares Shopify's positive experience during Black Friday/Cyber Monday 2021.
  7. HTTP RFCs have evolved: A Cloudflare view of HTTP usage trendsThis post details the publication of new RFCs for HTTP semantics, caching, HTTP/1.1, HTTP/2, and HTTP/3. It also presents an analysis of Cloudflare's HTTP traffic over the past year, showing trends in HTTP version usage across browsers (Chrome, Edge, Firefox, Safari), search engine bots (GoogleBot, BingBot), and social media bots. The analysis highlights the increasing adoption of HTTP/3, particularly by Chrome, and the slower adoption by search engine bots.
  8. Exported Authenticators: The long road to RFCThis post introduces Exported Authenticators (EAs) as a new extension to TLS. EAs provide application-layer authentication as strong as TLS authentication by using a trio of messages (Certificate, CertificateVerify, Finished) and tying this authentication to the TLS channel via channel binding. This prevents malicious servers from impersonating other servers by copying EAs between connections. The design of EAs hews closely to the TLS 1.3 handshake for security assurance and has undergone IETF standardization.
  9. Handshake Encryption: Endgame (an ECH update)This post announces the initial deployment of TLS Encrypted Client Hello (ECH), an extension to TLS 1.3 designed to encrypt sensitive metadata like the target server name during connection establishment. It details how ECH works by encrypting the ClientHello message using a public key advertised via an HTTPS resource record, and how the server decrypts it. The post contrasts ECH with DNS-over-HTTPS (DoH) and explains why ECH cannot be used for domain fronting due to its closed set of authorized domains. It also discusses the stronger threat model for ECH, which includes protecting against active and passive attackers inferring server identity from the anonymity set, and highlights the protocol's design to prevent cut-and-paste and masquerading attacks.
  10. From AMP to Signed Exchanges, Or How Innovation Happens at CloudflareThis post details the development of Signed Exchanges, a new protocol that builds on the principles of AMP to improve web performance and publisher control. It also discusses the role of the Emerging Technologies & Incubation (ETI) team in driving innovation and the importance of collaboration and open standards in advancing internet technologies.
  11. KEMTLS: Post-quantum TLS without signaturesThis post introduces KEMTLS, a novel approach to post-quantum TLS handshakes that replaces traditional signatures with post-quantum key exchange mechanisms (KEMs). It details the motivation for KEMTLS, stemming from the increased size and computational cost of post-quantum signatures compared to KEMs. The post explains how KEMTLS achieves authentication, confidentiality, and integrity, and discusses its implementation in Golang's TLS 1.3 suite, highlighting the reduction in handshake data size compared to traditional post-quantum TLS approaches.
  12. Better HTTP/2 Prioritization for a Faster WebIntroduces a new feature 'Enhanced HTTP/2 Prioritization' for paid plans, allowing site owners to override browser defaults with an improved scheduling scheme for faster visitor experiences. Details the background of web page resource loading, optimal resource ordering strategies, and contrasts the new server-controlled prioritization with suboptimal browser implementations (Microsoft Edge, Internet Explorer). Mentions Cloudflare Workers for further customization.
  13. Preventing Request Loops Using CDN-LoopThis post introduces the CDN-Loop header, a new mechanism for preventing request loops between CDNs. It details the problems with the previous Via header-based approach, including performance degradation and conflicts with existing usage. The post explains the syntax and implementation of the CDN-Loop header and announces its adoption at the Cloudflare edge, replacing CF-Connecting-IP and X-Forwarded-For for loop protection.
  14. Optimizing HTTP/2 prioritization with BBR and tcp_notsent_lowatThis post introduces specific kernel tuning parameters (BBR congestion control and tcp_notsent_lowat = 16KB) for Linux 4.9+ kernels to optimize HTTP/2 prioritization. It explains how excessive TCP send buffer buffering hinders HTTP/2's ability to interrupt low-priority responses for high-priority ones, and how tcp_notsent_lowat helps maintain minimal buffering to allow for immediate response switching.
  15. Verschlüsselung von SNI: Wie einer der großen Internet-Bugs behoben wurdeThis post introduces Encrypted SNI (ESNI) as a solution to the privacy leak in the unencrypted SNI extension. It details the problem of SNI revealing visited websites to ISPs and others, and how ESNI encrypts this information. Cloudflare is implementing ESNI across its network, and Mozilla's Firefox will be the first browser to support it. The post also mentions the collaborative effort with other industry players and the ongoing work on ESNI as an IETF draft RFC.
  16. A Detailed Look at RFC 8446 (a.k.a. TLS 1.3)This post introduces TLS 1.3 (RFC 8446) as a significant evolution of the Transport Layer Security protocol. It details the security and performance benefits of TLS 1.3 over TLS 1.2, including the removal of RSA key exchange and the streamlining of the handshake to a single round-trip. The post also touches on the historical context of TLS development and the discovery of various vulnerabilities in previous versions.
  17. Deprecating TLS 1.0 and 1.1 on api.cloudflare.comThis post announces the deprecation and eventual disabling of TLS 1.0 and 1.1 on Cloudflare's api.cloudflare.com and dashboard. It details the security vulnerabilities of these older protocols, provides a timeline for the deprecation, and outlines upcoming controls and analytics to help customers manage the transition. It also identifies problematic user agents and operating systems that may need upgrading.
  18. Deprecating SPDYThis post announces the deprecation of SPDY protocol support on Cloudflare's edge by February 21st, 2018. It details the history of SPDY as a precursor to HTTP/2, Cloudflare's decision to support both protocols for a transition period due to low HTTP/2 adoption, and the current state where SPDY usage has dropped to 3.83% of TLS connections. The post highlights the engineering cost of maintaining custom NGINX patches for SPDY support and the minimal impact of deprecation on users, primarily older iOS/macOS apps. It also notes that traffic using SPDY will gracefully fall back to HTTP/1.1. The decision to deprecate SPDY is framed as a necessary step in moving forward with newer, standardized technologies.
  19. Why TLS 1.3 isn't in browsers yetThis post details the challenges and evolution of TLS version negotiation, specifically focusing on the difficulties in deploying TLS 1.3 due to middlebox ossification and incorrect server implementations of version negotiation. It explains the history of insecure downgrades, the POODLE vulnerability, and the introduction of SCSV as a mitigation. The post highlights that while Cloudflare enabled TLS 1.3 server-side early, browser adoption has been slow due to these ecosystem-wide issues, particularly middlebox incompatibility with the new version negotiation mechanism.
  20. AES-CBC is going the way of the dodoThis post details the decline of AES-CBC cipher suites on Cloudflare's edge network, with ChaCha20-Poly1305 and AES-GCM becoming dominant. It also notes the surpassing of RSA by ECDSA for signatures and the high adoption of Perfect Forward Secrecy (PFS).
  21. So you want to expose Go on the InternetThis post details how to harden Go servers for internet exposure by tuning `crypto/tls` and `net/http`. It covers `crypto/tls` configuration for cipher suites, curve preferences, and certificate management with Let's Encrypt. It also discusses `net/http` timeouts (`ReadTimeout`, `WriteTimeout`, `IdleTimeout`), HTTP/2 behavior, TCP Keep-Alives, and best practices for `ServeMux` and logging. The core contribution is providing practical guidance and code examples for making Go services production-ready for the internet.
  22. HPACK: the silent killer (feature) of HTTP/2This post details the implementation of full HPACK header compression in nginx, including the upstreaming of Huffman encoding. It explains the HPACK algorithm's mechanisms (static dictionary, dynamic dictionary, Huffman encoding) and its resilience to attacks like CRIME. The post quantifies the performance gains, showing an average of 76% compression for ingress headers and 69% for egress headers, leading to substantial savings in total ingress traffic (53%) and a 1.4% saving in total egress HTTP/2 traffic. It also contrasts HPACK with previous compression methods used in TLS and SPDY.
  23. TLS nonce-nseThis post details the evolution of nonce management in TLS, from early stream ciphers like RC4 and CBC in TLS 1.0 (vulnerable to BEAST) to the more robust AEAD modes like AES-GCM in TLS 1.2 and the simplified, secure nonce scheme in TLS 1.3. It highlights the importance of nonce reuse resistance and the security implications of improper implementation, such as the 'Nonce-Disrespecting Adversaries' attack on AES-GCM. The post also touches on ChaCha20-Poly1305's similar nonce scheme to TLS 1.3.
  24. An overview of TLS 1.3 and Q&AThis post introduces TLS 1.3, highlighting its advantages over TLS 1.2. Key improvements include a reduced handshake time (1-RTT vs. 2-RTT for initial connections, and 0-RTT for subsequent connections), enhanced security by removing outdated and vulnerable cryptographic modes (e.g., static RSA, CBC MAC-then-Encrypt, RC4, SHA1, MD5), and simplified implementation. It details the handshake process for both TLS 1.2 and 1.3, explains session resumption, and discusses the caveats of 0-RTT (Forward Secrecy and replay attacks).
  25. Opportunistic Encryption: Bringing HTTP/2 to the unencrypted webIntroduced Opportunistic Encryption, enabling HTTP/2 connections for non-HTTPS sites by leveraging HTTP Alternative Services. This allows browsers to connect over TLS on port 443 using HTTP/2 or SPDY, providing encrypted connections and performance benefits without requiring a full HTTPS migration. This addresses mixed content issues and offers a security improvement over unencrypted HTTP.
  26. Introducing TLS 1.3This post announces the general availability of TLS 1.3 for all Cloudflare customers, enabled by default for Free and Pro plans. It highlights TLS 1.3's advantages in enhanced security by removing legacy, vulnerable cryptographic features and improved speed through a reduced handshake (one round-trip) and the upcoming zero round-trip (0-RTT) mode. The post details how to enable TLS 1.3 in Firefox Nightly and Chrome Canary.
  27. Encryption WeekThis post introduces TLS 1.3, Automatic HTTPS Rewrites, and Opportunistic Encryption. TLS 1.3 offers faster and more secure connections with fewer handshake messages. Automatic HTTPS Rewrites fixes mixed content issues by rewriting HTTP sub-resource URLs to HTTPS. Opportunistic Encryption allows HTTP sites to use encrypted HTTP/2 connections, providing encryption and performance benefits without a full HTTPS upgrade.
  28. Evenly Distributed FutureThis post discusses Cloudflare's role in making advanced internet technologies like HTTP/2, IPv6, HTML5, and TLS 1.3 available to all websites, regardless of size. It highlights how Cloudflare's platform allows customers to experiment with and adopt these new technologies, thereby distributing the 'future' of the internet more evenly. The post also touches on the challenges of keeping up with evolving technologies and security threats, and how Cloudflare's infrastructure helps bridge the gap between vulnerability disclosure and patching.
  29. Accelerating Node.js applications with HTTP/2 Server PushThis post introduces `netjet`, a Node.js middleware that parses HTML to automatically add `Link` headers for HTTP/2 Server Push. It details the implementation using PostHTML, discusses the trade-off of increased latency with an adjustable LRU cache, and provides examples for Express and raw Node.js HTTP servers. It also covers how to enable Server Push in Ghost and how to verify its usage in Chrome Developer Tools.
  30. HTTP/2 Server Push with multiple assets per Link headerThis post details an enhancement to Cloudflare's HTTP/2 Server Push implementation. Previously, only one asset could be pushed per `Link` header. This update allows for multiple assets to be specified in a single `Link` header, addressing limitations in CMS and web development platforms. A new header, `Cf-H2-Pushed`, has been introduced to provide visibility into which assets were pushed by Cloudflare, aiding in debugging.
  31. Optimizing TLS over TCP to reduce latencyThis post introduces an NGINX patch that enables dynamic TLS record sizing. The patch adds parameters `ssl_dyn_rec_size_lo`, `ssl_dyn_rec_size_hi`, `ssl_dyn_rec_threshold`, and `ssl_dyn_rec_timeout` to the NGINX SSL module. This allows TLS records to dynamically adjust their size based on the underlying TCP connection's state, starting small and growing larger as the connection stabilizes, and resetting to a small size during idle periods. This aims to reduce latency by minimizing delays caused by TLS record fragmentation across TCP segments, especially during TCP slow start or packet loss.
  32. Using HTTP/2 Server Push with PHPThis post details the implementation of HTTP/2 Server Push using PHP by adding `Link` headers with `rel=preload` to HTTP responses. It demonstrates how to use the PHP `header` function to achieve this, showing the effect on page load times and network waterfalls through browser developer tools and `chrome://net-internals/`. The post highlights the benefits of Server Push for preloading critical resources like images, reducing overall page load time.
  33. Open sourcing our NGINX HTTP/2 + SPDY codeThis post details the open-sourcing of Cloudflare's modifications to NGINX, enabling it to support both HTTP/2 and SPDY simultaneously. The patch allows NGINX to be built with both `--with-http_v2_module` and `--with-http_spdy_module`, and to accept both `spdy` and `http2` keywords for the `listen` directive. It utilizes ALPN and NPN for protocol negotiation, preferring HTTP/2 over SPDY/3.1 when both are offered. The post also provides instructions for configuring NGINX and testing protocol advertisement using OpenSSL.
  34. Announcing Support for HTTP/2 Server PushThis post announces the rollout of HTTP/2 Server Push for all Cloudflare customers, completing the set of HTTP/2 features. It details how Server Push works using PUSH_PROMISE and RST_STREAM, and how it can be enabled via Link headers with the 'rel=preload' directive. The post also explains how to disable Server Push using the 'nopush' directive and discusses its performance implications, best use cases (uncacheable content, all assets on a page, likely next page), and how to profile its benefits using browser developer tools. It highlights the potential for significant performance gains, especially on slower connections, and mentions future plans for automated Server Push optimization.
  35. IETF Hackathon: Getting TLS 1.3 working in the browserThis post details Cloudflare's participation in an IETF Hackathon focused on integrating and testing TLS 1.3, specifically between Firefox and Cloudflare's test site. The team successfully integrated TLS 1.3 into Firefox, enabling HTTPS requests and PSK-based session resumption. While 0-RTT was not fully functional for the demo, the effort proved invaluable for understanding practical implementation and interoperability challenges of TLS 1.3.
  36. What happened next: the deprecation of ANYThis post details Cloudflare's decision and implementation strategy for deprecating the DNS ANY meta-query type. It explains the rationale behind the decision, including the lack of legitimate use, abundance of malicious use, and its role in DNS amplification DDoS attacks. The post discusses the community conversation around the deprecation, the technical challenges of answering ANY queries (especially with DNSSEC), and the chosen approach of returning a 'harmless' HINFO record to recursive resolvers to minimize amplification factors while signaling non-support for the ANY query type. It also references the relevant IETF draft 'Refuse ANY'.
  37. It takes two to ChaCha (Poly)This post details the adoption and standardization of ChaCha20-Poly1305 as an AEAD cipher suite for TLS, providing an alternative to AES-GCM and improving performance, especially on mobile devices. It covers the history, standardization process, and technical differences between draft and RFC versions of the cipher suites, and their importance for the future of the web.
  38. Padding oracles and the decline of CBC-mode cipher suitesThis post details the historical issues with CBC-mode cipher suites in TLS, specifically the padding oracle attack and its timing-based variant. It explains how the unauthenticated padding in TLS records, combined with CBC's block chaining, creates vulnerabilities that allow attackers to decrypt sensitive data. The post highlights the shift towards more secure AEAD cipher modes, supported by increasing adoption in web clients, and advocates for the deprecation of CBC-mode cipher suites.
  39. Change the (S)Channel! Deconstructing the Microsoft TLS Session Resumption bugThis post details a bug in Microsoft's SChannel implementation that caused TLS 1.2 to downgrade to TLS 1.0 when presented with a renewed TLS session ticket during an abbreviated handshake. Cloudflare's investigation revealed that SChannel would abort the connection or downgrade when encountering an in-line `NewSessionTicket` message after an abbreviated handshake. Cloudflare's solution was to adjust its session ticket renewal strategy to avoid this problematic message flow for SChannel-based clients, ensuring continued TLS 1.2 support.
  40. CloudFlare’s Impact On The HTTP/2 “Universe”This post details the impact of Cloudflare's HTTP/2 rollout on overall HTTP/2 adoption. It presents data showing a significant increase in HTTP/2 capable browsers visiting Cloudflare.com and a doubling of HTTP/2 traffic ratio on www.cloudflare.com. It also highlights that Cloudflare's release more than quadrupled the number of websites with 'True Support' for HTTP/2, and improved HTTP/2's market position close to that of SPDY. The post also reminds customers that HTTP/2 is enabled by default for Free and Pro plans and can be enabled for Business and Enterprise plans.
  41. HTTP/2 Demo: Under the HoodThis post details the technical implementation of an HTTP/2 demonstration page. It explains how iframes were used to load content over both HTTP/1.1 (using Amazon CloudFront) and HTTP/2 (using Cloudflare's network) simultaneously for comparison. It describes the use of JavaScript to request 200 image tiles generated by ImageMagick, tracking load times and reporting metrics via `Window.postMessage` due to cross-domain security. It also covers the caching policy implemented to force edge caching and prevent browser caching, and discusses the SPDY fallback mechanism for browsers that do not support HTTP/2.
  42. HTTP/2 For Web DevelopersThis post details how HTTP/2 changes web optimization best practices for developers. It explains that instead of minimizing HTTP requests (as in HTTP/1.1), developers should focus on optimizing caching behavior by shipping small, granular resources. Key HTTP/2 features like multiplexing, header compression, stream prioritization, and server push are discussed. Specific HTTP/1.1 practices that are no longer recommended for HTTP/2 include concatenating files, inlining assets, and sharding domains. The post also reiterates that some HTTP/1.1 best practices remain relevant, such as reducing DNS lookups, using CDNs, leveraging browser caching, minimizing request/response sizes, and eliminating unnecessary redirects.
  43. SHA-1 Deprecation: No Browser Left BehindThis post details Cloudflare's implementation of SHA-1 fallback certificates for browsers that do not support SHA-2. This strategy ensures that users on legacy devices can still access encrypted content while modern browsers can deprecate SHA-1. The post includes data on global SHA-2 support, highlighting disparities in developing countries, and lists other major websites that also support SHA-1 fallback. Cloudflare also worked with Mozilla to test and refine this fallback mechanism.
  44. Tools for debugging, testing and using HTTP/2This post details tools and techniques for debugging, testing, and using HTTP/2. It covers browser extensions (HTTP/2 and SPDY Indicator, Claire), online testing tools, command-line utilities (is-http, curl with --http2, nghttp2 tools like nghttp and h2load, h2c, h2i), OpenSSL's s_client for protocol negotiation, and conformance testing tools (h2spec, h2scan). It highlights the release of HTTP/2 for all Cloudflare customers and the importance of using up-to-date browsers and tools for development and testing.
  45. HTTP/2 is here! Goodbye SPDY? Not quite yetThis post details Cloudflare's introduction of HTTP/2 support for all customers using SSL/TLS connections, while continuing to support SPDY. It explains the technical benefits of HTTP/2 and SPDY, such as multiplexing, stream dependencies, and header compression, and provides real-world performance data showing significant page load time improvements with HTTP/2. The post also addresses the decision to support both protocols simultaneously by analyzing usage data, highlighting the impact of deprecating SPDY prematurely on a significant portion of the user base. It details how to enable HTTP/2 for different customer plans and provides methods for checking server protocol negotiation using OpenSSL.
  46. Test all the things: IPv6, HTTP/2, SHA-2This post announces the launch of a test server at https://http2.cloudflare.com/ to test compatibility with IPv4/IPv6, HTTP/2, and SHA-2 certificates. It details the server's IP addresses, the SHA-256 certificate, and how to identify HTTP/2 usage in Chrome. The server is intended for testing purposes only and is not part of the main Cloudflare network. It highlights the deprecation of SHA-1 and the use of ECDHE for forward secrecy.
  47. 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, a memcached cluster is used within each PoP to share session data across hosts, achieving near 100% resumption rates. For Session Tickets, a key generation daemon generates and rotates encryption keys hourly, distributing them securely to all hosts without persistent storage. Technical details include handling distributed clock synchronization by generating keys an hour ahead and using decryption-only keys for robustness. Performance improvements are demonstrated with reduced connection costs and CPU usage.
  48. Do the ChaCha: better mobile performance with cryptographyCloudflare has added support for ChaCha20-Poly1305 cipher suites, which are optimized for mobile devices and offer improved performance and battery life compared to AES-GCM on hardware without AES acceleration. This move diversifies TLS cipher suites, providing a secure fallback option and enhancing overall security. The implementation leverages an open-source assembly code version of ChaCha/Poly for server-side optimization.
  49. The little extra that comes with Universal SSLThis post announces the rollout of SPDY 3.1 for all Cloudflare users, enabled by the Universal SSL feature. It highlights how SPDY, which requires SSL, improves performance by allowing browsers to query for multiple objects in one request and send them as they are ready. This expands the availability of SPDY to all sites on Cloudflare, not just large ones.
  50. The Web is World-Wide, or who still needs RC4?This post analyzes the continued need for RC4 cipher support in TLS connections, despite its known vulnerabilities. It details the breakdown of RC4 usage by client type (older phones, browsers, software updates, proxies) and geographic region. It also explains the RC4 algorithm and its historical context, and highlights the issue of transparent SSL proxies in institutions using outdated cipher suites. The post concludes with recommendations for users to check their SSL configuration and update software.
  51. Staying up to date with the latest protocols: SPDY/3.1This post details Cloudflare's rollout of SPDY/3.1 for all customers, highlighting its importance in keeping up with protocol evolution as older versions are deprecated. It explains the technical changes in SPDY/3 and SPDY/3.1, specifically flow control for individual streams, and discusses ongoing experimentation with QUIC, a UDP-based protocol.
  52. Using CloudFlare to mix domain sharding and SPDYThis post analyzes the performance implications of domain sharding in conjunction with the SPDY protocol. It demonstrates that while domain sharding was beneficial for HTTP/1.1 by increasing connection limits, it can negatively impact SPDY performance by forcing multiple SSL negotiations and connections. The post advocates for using a single certificate covering multiple subdomains to allow SPDY to multiplex requests over a single connection, thus achieving the best of both worlds for performance across different browser capabilities.
  53. A (Relatively Easy To Understand) Primer on Elliptic Curve CryptographyThis post introduces Elliptic Curve Cryptography (ECC) as a more secure and performant alternative to RSA for public key cryptography. It explains the mathematical underpinnings of ECC, contrasting it with RSA's reliance on factoring. The post details a toy RSA algorithm with a concrete example and discusses the limitations of RSA's trapdoor function due to advancements in factoring algorithms. It then introduces elliptic curves as a more suitable basis for future cryptographic systems.
  54. Why some cryptographic keys are much smaller than othersThis post explains the difference between symmetric and asymmetric cryptography, focusing on key lengths. It details how symmetric keys (like RC4 and AES) use a single key for encryption and decryption, with security derived from the sheer number of possible keys (e.g., 128-bit or 256-bit). It contrasts this with asymmetric keys (like RSA and ECDHE_RSA) which use a public/private key pair. The security of asymmetric cryptography relies on the difficulty of mathematical problems (e.g., factoring large prime numbers). The post explains why asymmetric keys need to be much larger (e.g., 2048-bit) than symmetric keys to achieve comparable security levels due to the mathematical patterns inherent in their generation, making them more susceptible to specific factorization attacks.
  55. SPDY Now One-Click Simple for Any WebsiteThis post announces the general availability of SPDY support for eligible Cloudflare customers. SPDY is now a one-click option for paying customers with SSL enabled, including those using Cloudflare's Flexible SSL. The post highlights the performance benefits of SPDY and Cloudflare's commitment to advancing web speed.
  56. What makes SPDY speedy?This post explains the technical underpinnings of SPDY, a protocol designed to make web browsing faster by sitting between HTTP and TCP. It details how SPDY achieves speed improvements by allowing a single connection for multiple asynchronous, overlapping HTTP requests, thereby minimizing connection setup time, TCP slow start penalties, and blocking issues inherent in traditional HTTP over TCP. The post also announces Cloudflare's upcoming beta availability of SPDY.
  57. Introducing SPDYIntroduced SPDY beta to Cloudflare customers, enabling connection multiplexing, out-of-order object retrieval, and HTTP header compression for faster page loads. Cloudflare acts as a gateway, allowing origin servers to not support SPDY directly. Integrated with Rocket Loader to further enhance multiplexing benefits, even for third-party scripts.
  58. Taming BEAST: Faster, Safer SSL now on CloudFlareCloudflare has implemented support for TLS 1.1 and 1.2, prioritizing RC4 cipher suites to mitigate the BEAST SSL attack. This also involved adding stronger cipher suites, removing weaker ones, and optimizing their prioritization for improved security and performance. The changes resulted in an approximate 30% increase in overall SSL performance, achieving a 90 (A) score on SSLLabs.