I care deeply about security and in this endeavor I often urge the use of Transport Socket Layer (TLS) Encryption be considered even for simple read-only services. One concern that was brought to my attention was the impact on network traffic. In high traffic environments, what impact does Security Certificates do to web traffic? Do I really need it?
The answer to these questions are difficult to answer. There are many variables to consider when investigating the impact of encrypted traffic on web pages. Some variables are:
- Is the page being requested in cache?
- How much processing is required to build the response if it’s not cached?
- How long might it take to encrypt the response before sending?
- Which encryption ciphers are being utilized? Does it make a difference?
- Is the content on this page worth encrypting in the first place?
- Am I likely to get the ugly “mixed content” message?
I’m not really going to dive into the specifics of the variables above in this post. The only thing I’m interested in for this particular post is the encryption, compression, and time to delivery or time on wire.
Alright. This topic is complicated and we are in the midst of a migration in our industry. TLS compression can make a real impact on page loads. The few additional cycles required to DEFLATE are minimal when compared to time-on-wire (TOW). Below are the results of an internal study that was done on our servers to determine if it was worth forcing some data over TSL simply to decrease the TOW.
The blue line above represents the distribution for TLS traffic. Red indicates standard traffic. As you can see it takes less time to transfer data over TLS. There is a large caveat to this information. TLS compression must be used and the browser or listener must support it. In this case, we are talking about Google’s SPDY (Speedy). This isn’t an acronym. It’s just dumb. If compression is turned off, the results are not so impressive.
The issue with SPDY is that support was not universal. Now that it was absorbed into HTTP/2 (RFC 7540), it’s on its way. Also, thanks to Compression Ratio Info-leak Made Easy (CRIME) attacks, the mitigation plan is underway to ensure those types of threats are addressed. I don’t see any reason that these attacks should detract from the potential up-side of compression + encryption.
Based on the outcome of my investigation, I recommended TLS be utilized for several specific purposes. We have been utilizing TLS 1.2 + compression for RESTful web services with great success and I believe when making the choice to secure content and allow compression of content, the benefits can truly outweighs any negative aspects.
I would love to hear any ideas or real world experiences anyone has on this topic.