For most of us, when we think “encryption,” we do not immediately think “high performance” or “easy.” However, advances in TLS (the successor to obsolete SSL) and other protocols as well as cipher implementations have greatly reduced the workloads associated with encryption—all while commodity processing power and capabilities continue to increase, despite apparent slow-downs in Moore’s Law. The only reason we still associate TLS encryption with high overhead and complexity is that we’ve mostly been concerned with maintaining high grades on SSL Labs.com for strong and effective encryption.
In speaking to many information security practitioners, SSL Labs grades and green browser address bars take a back seat if it affects page load time. Ilya Grigorik, web performance engineer and self-described “Internet plumber” at Google, launched IsTLSfastYet.com. His goal is to raise awareness around all the performance optimizations available to accelerate the adoption of TLS encryption. On this site as well as his blog, Grigorik covers the finer points in great detail. At a high level, whether you’re seeking to improve TLS performance via a CDN or by tuning your server, load balancer, or other proxy, there are some key features that should be supported by any system or service that terminates TLS.
- Start at layer 4. Communications over TLS require different TCP tuning and optimization than clear-text communications via HTTP only. Many performance problems perceived to be TLS overhead are actually the result of poorly tuned TCP settings. Ensure that any system or service terminating TLS enables appropriate tuning of TCP.
- Eliminate redirects. Redirecting HTTP requests to HTTPS is a common practice for identifying certain hostnames that require HTTPS. However, redirects affect user experience and page load time. By using HTTP Strict Transport Security (HSTS) headers, all requests will come directly via HTTPS, and by using Server Name Indication (SNI), a single IP endpoint can handle multiple hostnames and associated certificate/key pairs.
- Prefer Forward Secrecy. Today, Perfect Forward Secrecy (PFS) is enabled via DHE and ECDHE ciphers and, in general, facilitates the use of TLS False Start. Fortunately, Forward Secrecy is one of the key components in the SSL Labs rating criteria and enabling the best possible privacy via TLS, and is easily tested via SSLLabs.com.
- Support ALPN. Application Layer Protocol Negotiation is part of the now-deprecated SPDY protocol from Google. ALPN succeeded NPN, and is a method by which the application layer protocol to be run over TLS can be negotiated ahead of time, and enhances performance by reducing round trips. The main mechanism for enabling ALPN is via moving to the HTTP/2 protocol, which is transported via TLS by default.
- Session identifiers and tickets. Some real nitty gritty aspects of the TLS protocol greatly affect performance, depending upon whether they’re enabled. Session Identifiers (RFC 5246) enable TLS session resumption, which has the effect of eliminating new TLS handshakes (and round trip plus encryption overhead associated). Session Tickets (RFC 5077) enhance Session Identifiers by eliminating the need for the server to cache every Session Identifier by providing the client with a Session Ticket.
- Enable Dynamic Record Sizing. Dynamic Record Sizing reduces and optimizes the overhead of TLS framing. From O’Reilly’s High Performance Browser Networking: “Using a dynamic strategy delivers the best performance for interactive traffic: small record size eliminates unnecessary buffering latency and improves the time-to-first-{HTML byte, …, video frame}, and a larger record size optimizes throughput by minimizing the overhead of TLS for long-lived streams.”
- OCSP Stapling. The Online Certificate Status Protocol (OCSP) helps solve the problem of establishing the authenticity of a given certificate without shipping a library of known certificates with every client, as with Certificate Revocation Lists (CRLs). However, OCSP induces a lot of latency via the addition of round trips between the client and the issuing Certificate Authority (CA). OCSP Stapling enables a TLS server to “staple” or cache a digital signature from the issuing CA to the certificate, thereby eliminating round trips from the browser.
As the march toward HTTPS everywhere continues, information security practitioners need to be armed with the tools to ensure that encryption never sacrifices performance. Page load times are a vital metric for how sticky or popular a site or service might be, and increasingly, the quality of the encryption (as determined by the browser and/or SSL Labs) has become another factor for both search-index rank and customer preferences. Encryption via TLS is at a critical intersection of performance and security and, as such, requires focused attention. Selecting and configuring TLS-based systems and services capable of performance optimizations is vital to the success of any Internet-based application.
As a Senior Security Solutions Architect at F5 Networks, Brian McHenry focuses on web application and network security. McHenry acts as a liaison between customers and F5 product teams, providing a hands-on, real-world perspective. He is a regular contributor on InformationSecurityBuzz.com, a co-founder of BSidesNYC, and a speaker at AppSecUSA, BC Aware Day, GoSec Montreal, and the Central Ohio Infosec Summit, among others. Prior to joining F5 in 2008, McHenry, a self-described IT generalist, held leadership positions within a variety of technology organizations, ranging from startups to major financial services firms.
The opinions expressed in this post belong to the individual contributors and do not necessarily reflect the views of Information Security Buzz.