WebPerf The SSL Performance Myth, and Tips for Making Secure Connections Fast

We’re not shy about touting the virtues of SSL. In fact, we encourage our customers to encrypt their websites whenever possible. Despite its growing relevance, one of the most common arguments we hear against the adoption of SSL is that it’s too slow.

In this post, we examine some claims behind this argument and current technologies being used to debunk them. For instance, it’s important to understand that even in an infrastructure as big as Google’s, SSL has limited impact on web performance. (That impact is 2% on network overhead and p>
Before we get started, let’s clarify the difference between SSL and the often misunderstood TLS.

SSL and TLS: What’s the Difference?


The short answer is: There is no difference. TLS is the successor to SSL 3.0 and was designed to resolve insecurities in the SSL protocol. We refer to TLS as SSL because the protocol started with SSL and the term stuck. SSL was superseded by TLS in 1999.

Myth: SSL Is Computationally Expensive


It’s no secret that encrypted websites are more resource-hungry than unencrypted websites. While the encryption process might have been CPU intensive years ago, today’s consumer-grade hardware can handle it quite easily. Even a 2012 MacBook Air can sign an SSL key in only 6.1 milliseconds.

First Contact


The most resource-intensive part of any SSL connection is its creation. As part of the initial connection process, the client (e.g. a web browser) and the server exchange information using a process known as asymmetric encryption. Asymmetric encryption is slow, but it establishes a secure communications channel through which a session key is exchanged. This session key allows the client and the server to switch to a faster encryption process known as symmetric encryption.

This process might sound complicated, but it has a minor impact on response time. Tests comparing encrypted connections to unencrypted connections show a difference between encrypted and unencrypted response times of 5 ms, with a peak increase in CPU usage of about 2%. Even with dozens of parallel requests and hundreds of sequential requests, CPU usage never exceeded 5%.

Taking Advantage of Hardware


SSL contains a number of cipher suites, which are the algorithms and keys used to secure a connection. One of the most popular ciphers, the Advanced Encryption Standard (AES), has had dedicated instructions added to modern CPUs, helping it run substantially faster than ciphers implemented in software.

Mozilla has compiled a suggested web server configuration using modern ciphers that take advantage of hardware support.

Myth: SSL Is Network Intensive


SSL has a smaller impact on network performance than you might think. Encryption does add a step in the initial connection process, but the overhead for ongoing connections is negligible when compared to unencrypted connections.

When a client connects to an SSL-enabled server, both parties go through a process of verifying the other’s identities and establishing the methods used for encryption, adding an extra round of communication before data can be transmitted. Two technologies known as False Start and Session Resumption are designed to reduce this performance hit without hurting security.

False Start


False Start speeds up the initial connection process by giving the sender a head start on the receiver. A normal TCP connection (known as a TCP handshake) forces one party to wait for a response from the other before continuing. With false start, the sender starts sending data when the handshake is only partially complete. By the time the handshake is finished, data has already been transferred.

False start works by changing the timing of the handshake. Once the client exchanges its key with the server, it can begin encrypting messages that it knows the server will be able to decrypt. The next step in the handshake is simply verifying that the handshake hasn’t been tampered with. False Start requires NPN and forward secrecy to be configured on your web server.

Session Resumption


Session Resumption caches keys and connection information on both the client and the server. When a client connects to a familiar server, both parties check and compare their caches for matching session IDs and parameters. Matching sessions result in a shorter handshake, while new connections result in a newly created session ID. While this reduces the number of round trips, it requires the server to maintain a list of thousands or possibly millions of unique session IDs.

Session tickets were introduced to fix the problem of large server caches. With session tickets, the server uses a key that only it knows to encrypt session information before storing it on the client. The next time the client connects to the server, the server decrypts and reuses the session information.

Session tickets provide all of the benefits of session resumption – fewer computations, fewer roundtrips, and a lower congestion window – without bogging down your server. You can check if your web server supports session resumption using Qualys’ SSL Server Test.

---

Case In Point: Facebook Switches to SSL


In 2013, Facebook switched its services to HTTPS. What began as an optional account setting two years earlier became the default for all of Facebook’s 1 billion plus users. Facebook recognized that SSL’s extra round trips could cause delays for some users, but two techniques helped them minimize and – in many cases – eliminate the extra latency.

Leveraging Edge Networks


Facebook’s expanded infrastructure allows it to shorten the gap between its data centers and its users. As requests pass through the edge network, Facebook optimizes and reshapes the requests while reusing existing connections to its data centers. Adding its own servers to ISP point of presence facilities helps customers connect to Facebook without having to make several additional hops over the Internet.

In addition to leveraging these edge networks, Facebook also uses three CDNs in its multi-CDN strategy.

Reducing Handshakes


Taking advantage of session resumption lets Facebook cut handshake times in half. Although first-time requests still require a full handshake, sessions stored in the cache can shave a full round trip off of subsequent requests. While this does mean a delay of a few milliseconds for first-time visitors, any delays caused by following connections will be even smaller. With session tickets, Facebook can reduce its network load without making a single change to its servers.

Other Ways to Secure Connections While Preserving Performance


By implementing the performance optimizations mentioned above, your users will enjoy an online experience that’s both fast and secure. And when HTTP/2 is released, the secure connections your users initiate will be even faster. Combine the optimizations mentioned above with those listed below.

Consider Using Elliptic Curve Cryptography


Elliptic Curve Cryptography (ECC) is a form of cryptography that provides high levels of security using smaller keys, making it more efficient to calculate and transmit encrypted communications. ECC is supported by most modern browsers and web servers, but requires an ECC certificate from your certificate’s vendor.

Enable SPDY (Until HTTP/2 Launches)


Serving as the basis for the HTTP’s makeover, SPDY improves SSL’s performance by addressing some of HTTP’s underlying issues: single-request connections, uncompressed data, and redundant HTTP headers. Enabling SPDY on your CDN as well as your main server is your best bet until HTTP/2 is released.[Update] HTTP/2 is here!


Related Blog Post: 3 Things CDN Users Need to Know About HTTP/2

Enable OCSP Stapling


This checks an SSL certificate against the certificate’s vendor to ensure its validity. Normally this requires an extra connection as the browser communicates with the vendor, but OCSP stapling removes that step by storing the vendor’s response on the server itself. Our visual glossary article on OCSP stapling contains instructions on how to enable it for Apache and Nginx.


Related Blog Post: Enable OCSP Stapling on MaxCDN

Conclusion


While SSL can impact the performance of your website, its effects are minor. Also, saving a few milliseconds will never outweigh the level of security SSL affords. With the forthcoming HTTP/2 and all the SSL optimizations you can implement, the amount of milliseconds SSL adds to connections will only continue to drop.

The post The SSL Performance Myth, and Tips for Making Secure Connections Fast appeared first on MaxCDN Blog.

Continue reading...