In this article, we address the main reasons why TLS impacts the performance of your digital services. Let’s begin by breaking open doors: securing your web applications must be one of your main concerns and priorities when deploying new digital services!
This is obviously of upmost importance for protecting your services as well as users, but is also since a very long time one of your services SEO score drivers.
Securing a digital service means:
- ensuring transmitted data privacy through encryption
- verifying identity (potentially from both sides of the communication) through authentication
- ensuring transmitted data integrity through hashing
The standard protocol used to provide these functionalities is TLS.
TLS introduction
TLS stands for Transport Layer Security and is an evolution of the SSL (Secured Socket Layer) protocol, initially developed by Netscape, back in the 90’s. This is a summary of the TLS evolution:
| Protocol version | Date | RFC standard |
| TLS 1.0 | January 1999 | First IETF version : RFC 2246 |
| TLS 1.1 | April 2006 | RFC 4346 |
| TLS 1.2 | August 2008 | RFC 5246 |
| TLS 1.3 | March 2018 | RFC 8446 |
TLS was initially developed on top of reliable protocols like TCP, enabling protocols above it (HTTP, email, instant messaging, …) to operate securely. So this was not meant to be used only for web transactions but this is of course the most well-know application that makes use of it.
Securing web transactions through HTTPS
Both IETF (Internet Engineering Task Force) and IAB (Internet Architecture Board) has issued guidance to developers and protocol designers that strongly encourages adoption of HTTPS.
Starting with HTTP/2, TLS 1.2 protocol or higher is required! So you’ll never be able to run HTTP/2 as unprotected HTTP transaction.
Furthermore, TLS has also been adapted to run over datagram protocols like UDP. The DTLS (Datagram Transport Layer Security) protocol, defined in RFC 6347, is based on the TLS protocol. This makes TLS also the security protocol of choice for HTTP/3 transactions.
Performance challenges of using TLS over HTTP
Before the client and the web server can begin communicating data safely, they must negotiate the way they will secure the session. The client and the server must:
- agree on the TLS protocol version to use
- choose the cipher suite
- verify certificates if necessary
First, this negotiation process adds CPU overhead at both sides of the communication. Fortunately, thanks to the more optimized newest TLS versions as well as modern hardware components, this is not considered as being a major issue anymore.
So let’s only focus on the second performance driver, that is the extra delay introduced by the additional network round trips required…
As you can see, a traditional TLS handshake process requires two full round trips.
Taking the example of a communication between New York and Sydney, the additional introduced delay will typically be between 400 and 600 ms!
As you can imagine, this additional round trips can really affect overall web performances.
How to minimize the performance impact of using TLS
There are two main factors you can try to work on in order to minimize the performance impact TLS will have on your communications. You can:
- improve the network performance
- reduce the number of round trips required to set up TLS
How to improve network performance
There are basically two ways to reduce the time required to send data from one point to another.
The first one consists of improving the performances of the network itself. Obviously, the speed of light is the physical limit you cannot exceed… But the network components themselves drive other aspects of the network transmission, like processing & serialization, as well as queuing.
Bad quality networks also often lead to high packet retransmission rates, that in turn affect network performance.
The second way to reduce the data transmission delay is by hosting the requested digital resources as close possible to the clients. Smaller distance means lower latency. Techniques like caching resources, or using CDN (Content Delivery Network) providers should be considered to ensure proper digital services performance, independently of the users’ locations.
How to reduce the number of required round trips
Establishing a TLS session generally requires 2 full round trips. What if you were able to modify the TLS handshake structure so that fewer round trips were required? It would definitely reduce the overall time spent on this secure session setup, right? Well, there are some techniques available to achieve this.
TLS resumption
In case the client has previously communicated with the server, it may be able to reuse the already negotiated parameters for new secure sessions. In such a case, as illustrated hereunder, this reduces the TLS handshake process to only one round trip.
False Start
False Start is a TLS protocol extension that allows the client and server to start transmitting encrypted application data when the handshake is only partially complete.
In this case, as soon as the client sends the encryption key to the server, it does not wait for the answer before transmitting effective data.
Most of the browsers today do support False Start, but this is not the case of all servers.
Perfect Forward Secrecy (PFS)
For years, RSA handshake has been the dominant key exchange mechanism in most TLS deployments. But RSA has one major security weakness: the same public-private key pair is used both to authenticate the server and to encrypt the symmetric session key sent to the server. By contrast, the Diffie-Hellman key exchange allows the client and server to negotiate a shared secret without explicitly communicating it in the handshake.
Furthermore, Diffie-Hellman can be used to generate a new ephemeral symmetric key as part of each and every key exchange and discard the previous key. So even if a session key is compromised, it cannot be used to decrypt previous sessions…
Perfect Forward Secrecy means combining False Start with Diffie-Hellman key exchange mechanism.
Why does this matter from a performance standpoint? Well, many browsers enable certain protocol optimizations only when PFS is available. One important example is the 1-RTT handshake process with TLS False Start. So you see how good security and performance go sometimes hand in hand.
TLS 1.3
TLS 1.3 has been published in August 2018 under RFC 8446.
Compared to its counterpart TLS 1.2, it introduces new features to enhance the security as well as the performance of secure communications.
First, the TLS 1.3 handshake process only requires 1 round trip.
Resuming a TLS session is also much faster with TLS 1.3 as this protocol support the “0-RTT round trip” resumption! This is due to the fact that TLS 1.3 requires Diffie Hellman as key exchange mechanism. RSA has been removed due to the security concerns mentioned before. In TLS 1.3, a client can send data on the first message to the server by leveraging pre-shared keys (PSK) from the prior session, thus 0-RTT.
The importance of monitoring TLS
Securing web communications through TLS is a must today. It is so true that HTTP/2 and HTTP/3 newest protocols make the use of TLS mandatory! But securing communications has an impact on the performance. The impact not only depends on the network conditions (network quality and distance between client and digital resources), but also on the TLS version used because each successive version comes with possible performance improvements. And the TLS version used depends not only on the server configuration, but also on the clients (browser) capabilities.
As explained in this article, deploying your digital resources as close possible to your users really helps improving performances. You’ll typically achieve this by contracting hosting services with CDN providers. But all CDN providers do not offer the same level of capabilities in terms of HTTP(S) protocols support and TLS features. in other words, what you gain in performance on one side may be at the expense of said performance on the other side.
So when monitoring the TLS handshake process time and potential negotiation errors, you should be able to correlate these data with the targeted resources as well as clients. Examples of questions you should be able to answer are:
- Where are the digital resources located (which CDN provider, …)?
- What is/are the HTTP protocol(s) used to fetch them?
- Are there any performance issues depending on the users’ location, used devices and/or used browser?
- Are there any specific error impacting users? For which resource(s)? Which region in the world?
The screenshot below is a real world example. Establishing the TCP session to fetch the corresponding resource using HTTP/2 takes 81ms, while securing the session through TLS takes 288 ms!
TLS definitely impacts performance.
If you want to know more about how you can track end-to-end digital experience of modern applications, please continue your reading here…
