https://DevOpsCloud.io -- Cloud Monk Losang Jinpa

Return to SSL/TLS, Network Performance, Network Speed, Network Latency, Network Throughput, Encryption, Cryptography

TLS has exactly one performance problem: it is not used widely enough.

Everything else can be optimized.

Data delivered over an unencrypted channel is insecure, untrustworthy, and trivially intercepted. We owe it to our users to protect the security, privacy, and integrity of their data — all data must be encrypted while in flight and at rest. Historically, concerns over performance have been the common excuse to avoid these obligations, but today that is a false dichotomy. Let's dispel some myths.

The process of establishing and communicating over an encrypted channel introduces additional computational costs. First, there is the asymmetric (public key) encryption used during the TLS handshake. Then, once a shared secret is established, symmetric encryption takes over.

1. upgrade to latest

$> openssl version OpenSSL 1.1.1a 20 Nov 2018

1. run benchmarks

$> openssl speed sha $> openssl speed ecdh Good news is, modern hardware has made great improvements to help minimize these costs, and what once may have required additional hardware can now be done efficiently by the CPU.

On our production frontend machines, SSL/TLS accounts for less than 1% of the CPU load, less than 10 KB of memory per connection and less than 2% of network overhead. Many people believe that SSL/TLS takes a lot of CPU time and we hope the preceding numbers will help to dispel that. - Adam Langley, Google “Overclocking SSL” We have deployed TLS at a large scale using both hardware and software load balancers. We have found that modern software-based TLS implementations running on commodity CPUs are fast enough to handle heavy HTTPS traffic load without needing to resort to dedicated cryptographic hardware. - Doug Beaver, Facebook “HTTP2 Expression of Interest” Elliptic Curve Diffie-Hellman (ECDHE) is only a little more expensive than RSA for an equivalent security level… In practical deployment, we found that enabling and prioritizing ECDHE cipher suites actually caused negligible increase in CPU usage. HTTP keepalives and session resumption mean that most requests do not require a full handshake, so handshake operations do not dominate our CPU usage. We find 75% of Twitter’s client requests are sent over connections established using ECDHE. The remaining 25% consists mostly of older clients that don’t yet support the ECDHE cipher suites. - Jacob Hoffman-Andrews, Twitter “Forward Secrecy at Twitter” Before the client and the server can begin exchanging application data over TLS, the encrypted tunnel must be negotiated, which introduces additional roundtrips for each new connection. However, we don't have to incur the cost of a full handshake in every case: TLS resumption and TLS False Start decrease the cost to a single roundtrip for new and returning clients.

A well tuned TLS deployment can make an enormous positive difference in the user experience, as well as in your operational costs. Some of the most critical features and concepts:

TLS handshake TLS session resumption TLS False Start TLS record size optimization Early termination HTTP Strict Transport Security (HSTS) To deliver the best performance, run down the TLS performance checklist and use a tool like Qualys SSL Server Test to scan your server for common configuration and security flaws.

High Performance Browser Networking

What every developer should know about networking and web performance.

Read HPBN online Server performance TLS exposes many different knobs and new config flags on every server. Our goal here is not to provide an exhaustive list (consult server docs for that), but to highlight status of important performance-oriented features: resumption, stapling, false start (requires ALPN and forward secrecy), and support for the HTTP/2 protocol.

	Session identifiers	Session tickets	OCSP stapling	Dynamic record sizing	ALPN	Forward secrecy	HTTP/2	TLS 1.3	TLS 1.3 0-RTT

Apache yes yes yes yes yes yes yes yes no ATS yes yes yes dynamic yes yes yes yes no Caddy yes yes yes yes yes yes yes yes no F5 BIG-IP yes yes yes yes yes yes yes yes no H2O yes yes yes dynamic yes yes yes yes yes HAProxy yes yes yes dynamic yes yes yes yes yes Hitch yes yes yes no yes yes yes yes no IIS yes yes yes no yes yes yes yes no Citrix ADC yes yes yes no yes yes yes yes no lighttpd no yes yes no yes yes yes yes no NGINX yes yes yes static (16k) yes yes yes yes yes node.js yes yes optional optional yes yes yes yes no Go yes yes optional yes yes yes yes yes no nghttpx yes yes yes dynamic yes yes yes yes yes Pulse Secure vTM yes yes yes no yes yes yes yes no ShimmerCat yes no no yes yes yes yes no no Your favorite server missing, or found an error? Open a pull request!

CDN & PaaS performance Using a CDN allows us to terminate the connection close to the user, which can significantly reduce the cost of TCP and TLS handshake - see early termination. For best results you should be using a CDN to serve both static and dynamic content.

	Session identifiers	Session tickets	OCSP stapling	Dynamic record sizing	ALPN	Forward secrecy	HTTP/2	TLS 1.3	TLS 1.3 0-RTT

Akamai yes yes yes configurable (static) yes yes yes yes no AWS ELB (Classic) yes yes no no no yes no no no AWS ELB (Application) yes yes no no yes yes yes no no AWS CloudFront no yes yes no yes yes yes yes no BelugaCDN yes yes yes dynamic yes yes yes no no CDN77 yes yes yes dynamic yes yes yes yes yes Cloudflare yes yes yes dynamic yes yes yes yes yes ChinaNetCenter yes yes no no no yes no no no EdgeCast no yes yes no yes yes yes yes no Fastly yes yes yes dynamic yes yes yes yes client→Fastly only Google App Engine yes yes no dynamic yes yes yes no no Heroku yes yes no no no yes no yes no Imperva Incapsula yes yes yes dynamic yes yes yes no no Instart yes yes yes configurable (static) yes yes yes yes yes KeyCDN yes yes yes configurable (static) yes yes yes yes yes Limelight yes yes configurable no yes yes yes yes no StackPath yes yes yes no yes yes yes yes no Netlify yes yes no dynamic yes yes yes yes no QUANTIL yes yes no no no yes no no no Vercel Edge Network yes yes yes no yes yes yes yes no Your favorite CDN or PaaS provider missing, or found an error? Open a pull request!

FAQ What about benchmarks? Quality of implementation matters — no argument there — and you should do your due diligence. That said, you need to test on your own hardware and with realistic traffic patterns to get an accurate picture of what works best for your specific workload. Don't trust outdated benchmarks, update your OpenSSL libraries, update your server, and run the tests.

TLS operational costs are still higher, right? Not necessarily. Once you enable and optimize your TLS stack you're also well on your way to deploying HTTP/2. Unlike HTTP/1.1, HTTP/2 requires only a single connection per origin, which means fewer sockets, memory buffers, TLS handshakes, and so on. As a result, it may well be the case that you will be able to handle more users with fewer resources.

TLS still adds an extra RTT; can we fix that? One possible route is to leverage TCP Fast Open, which would allow us to send the ClientHello within the TCP SYN packet — that would cut another RTT. In the meantime, both TLS 1.3 and QUIC are experimenting with “zero-RTT” handshake mechanisms. See QUIC crypto doc and this GDL episode for a general introduction to QUIC.

Which ciphersuite should I be using? Mozilla maintains a wiki page with a recommended ciphersuite list and server configuration tips.

If TLS False Start is enabled, do I need resumption? Both resumption and TLS False Start eliminate an extra roundtrip from the TLS handshake. However, resumption also allows you to skip the asymmetric handshake crypto by reusing parameters from a previous session — this saves CPU cycles. In other words, yes you need both.

I run a multi-server deployment. Any tips? Ensure you have a shared session cache to get a good cache hit rate on resumed sessions across different servers. Also, ensure you expire and rotate your sessions and session ticket keys in a secure manner, especially when forward secrecy is enabled.

What about certificate costs? You can get free certificates for any use from Let’s Encrypt. If you need EV verification, then you will have to pay a bit extra. Use your favorite search engine to look for and evaluate the available options. The security and integrity of your visitors' data is worth every penny!

What about Elliptic Curve Cryptography (ECC) certificates? ECC certificates offer stronger security and smaller certificates - e.g. a 256-bit ECC key is equivalent to a 3072-bit RSA key. ECDSA certificates are recommended for modern TLS clients, such as web browsers, but if you need to support legacy clients (e.g., OS/software from 2008 or earlier often found in enterprise environments) that lack ECDSA support, you can provide RSA as a fallback via a hybrid certificate. Consult the documentation of your server to see if RSA+ECDSA is a supported option.

What about CRIME and BREACH attacks? CRIME is an attack against compression at the TLS layer. All modern user agents disable TLS compression, but it is still recommended that you disable TLS compression on your server. BREACH, on the other hand, is an attack against compression on top of TLS (e.g. HTTP compression) and must be mitigated both at the server and application levels - read more.

How do I migrate my existing site to HTTPS? Checkout the HTTPS Everywhere presentation (slides) from Google I/O to learn the best practices and the steps to safely migrate your existing content to HTTPS.

Why do we need HTTPS everywhere? Every unencrypted HTTP request reveals information about user’s behavior. Today, there is no such thing as insensitive web traffic - read more.

Where can I learn more about TLS performance? Is TLS Fast Yet? video from Velocity SC 2014 (slides). High Performance Browser Networking contains a full chapter on TLS performance.

Fair Use Sources:

• https://istlsfastyet.com