May 18, 2022

The benefits of using TLS 1.3 and 0-RTT on web servers such as NGINX

Let's see how to improve the speed and performance of our NGINX web server thanks to TLS 1.3 and 0-RTT

TLS 1.3 Banner and HTTPS

Finally, in 2022 it now seems established that it has become rather easy to bring a web project online that can run decently and bring satisfaction and profits.

However, it must be taken into account that we are always in fierce competition in all the facets that can help decree the success of our web project.

Unfortunately, there is no luxury of being able to do things well, or well, we must always try to do things at their best in an optimal and maniacal way to be able to guarantee results and advantages over the competition.

Having a slow or non-indexed site becomes just an unnecessary cost that will never give you professional and economic satisfaction. This is why you should always and only surround yourself with esteemed and competent professionals in their field and in the case of hosting and web performance you can rely on us.

Among the many fundamental aspects such as development, SEO, Copy, one of the aspects not to be overlooked is in fact that of the speed and responsiveness of the website both for search engines such as Google and for the user. We have written a lot about it, devising specific services for those users who do not like to compromise on performance, without having to spend considerable amounts in the order of thousands of euros per month.

In short, we have made high-performance hosting services popular and accessible, combining research and development. Looking around and weighing the most famous sites in the Italian panorama we were able to verify that almost all the websites do not adopt TLS 1.3 and above all the 0-RTT which in our case allowed, for example, to recover over 150 ms of total TTFB, on a total expense of about 500ms, improving the speed by about 25%.

In this article, I will explain the benefits of using TLS 1.3 and 0-RTT in web servers such as NGINX, the most popular web server we have discussed so much about at this article.

Transport Layer Security (TLS) is a cryptographic protocol used to secure communications between clients and servers over the Internet or other networks. Provides protection of the privacy and integrity of data exchanged over unsecured networks such as the Internet. It also allows client / server applications to authenticate each other, allows users to verify if they are connected to the intended server, and optionally provides mutual authentication (the server proves its identity to the client). The latest version of TLS at the time of writing is 1.3.

The cost of latency

A big component of web performance is transmission latency. Simply put, transmission latency is the amount of time it takes for a message to travel from one party to another on a network. Lower latency means faster web pages and more responsive APIs; when it comes to responsiveness, every millisecond counts.

The following diagram is derived from a recent Cloudflare network latency test using the RIPE Atlas project. In the experiment, hundreds of probes from around the world sent a single message "Ping" to Cloudflare and measured the time it took to get a response in response. This time is a good approximation of the time it takes for the data to make the round trip from the probe to the server and back, the so-called round-trip latency.

Latency is usually measured in milliseconds or thousandths of a second. A thousandth of a second may not seem like a long time, but they can add up quickly. IS generally accepted that the threshold beyond which humans no longer perceive something as instantaneous is 100 ms. Anything above 100ms will seem fast, but not immediate. For example, Usain Bolt's reaction time out of the starting blocks in the XNUMXm sprint is approximately 155 ms, a good reference point for thinking about latency. We use 155 ms, as a fast but human perceptible amount of time, as a unit of measurement of time.

Round-trip latency makes a big difference for HTTPS. When making a secure connection to a server, there is an additional setup step that can take up to three messages to make the round trip between the client and server before the first request can even be sent. For a visitor 250ms away, this can result in an excruciating one second (1000ms) delay before a site starts loading. During this time Usain Bolt ran 10 meters and you are still waiting for a web page. TLS 1.3 and 0-RTT cannot reduce the round-trip latency of a transmission, but they can reduce the number of round-trips required to set up an HTTPS connection.

HTTPS round trip

For a browser to download a webpage over HTTPS, there is a setup that goes behind the scenes. Here are the 4 steps that must occur the first time your browser attempts to access a site.

Step 1: DNS Lookup

Your browser needs to convert the website hostname (e.g. blog.cloudflare.com) to an Internet IP address (such as 2400: cb00: 2048: 1 :: 6813: c166 or 104.19.193.102) before it can connect to it . DNS resolvers managed by your ISP usually cache the IP address for popular domains, and your ISP's latency is quite low; therefore, this step often takes a negligible amount of time.

Phase 2: TCP Handshake (1 round trip)

The next step is to establish a TCP connection to the server. This phase consists of the client sending a SYN packet to the server and the server responds with an ACK packet. The details don't matter as much as the fact that this requires the data to be sent from the client to the server and vice versa. This requires a round trip.

Step 3: TLS handshake (2 round trips)

At this stage, the client and server exchange cryptographic key material and establish an encrypted connection. For TLS 1.2 and earlier, two round trips are required.

Step 4: HTTP (1 return)

Once the TLS connection is established, your browser can send an encrypted HTTP request using it. It can be a GET request for a specific URL like https://managedserver.it, for example. The server will respond with an HTTP response containing the HTML of the web page and the browser will start displaying the page.

Assuming DNS is instant, there are 4 round trips left before the browser can start showing the page. If you are visiting a site you have recently connected to, the TLS handshake phase can be reduced from two round trips to one with the TLS session resuming.

This leaves the following minimum waiting times:

  • New connection: 4 RTT + DNS
  • Connection resumed: 3 RTT + DNS

How does TLS 1.3 and 0-RTT improve connection times?

One of the biggest advantages of TLS 1.3 over previous versions is that it only requires a round trip to set up the connection, resume or not. This provides significant speed for new connections, but none for resumed connections. Our measurements show that around 40% of HTTPS connections are resumed (via session ID or session ticket). With 0-RTT, a round trip can be eliminated for most of that 40%.

How does TLS work?

To establish a secure connection between two parties - typically a browser (client) and a web server - one party must generate a private key (which only she knows) and a public key certificate that contains both keys along with information about her identity.

TLS establishes an exchange of keys called Handshake (handshake) using several and fast steps which however require a data transfer and obviously a very short time expenditure (150/250 ms).

It is therefore obvious that by being able to save time in the negotiation of keys, it is possible to improve navigation speed and thus obtain better performances that can already be appreciated even with the naked eye.

What is TLS 1.3?

TLS 1.3 is the latest version of the Transport Layer Security (TLS) protocol. TLS 1.3 was officially released in August 2018 as RFC 8446, replacing TLS 1.2, released in 2008. The main reason for the update was to improve the security and privacy of Internet communications. These improvements include:

Enhanced Security: TLS 1.3 uses a new cryptographic suite based on Diffie-Hellman elliptic curve key exchange (ECDHE) and HMQV key agreement with forward secrecy (FS). It also uses data-authenticated encryption (AEAD), which ensures confidentiality and integrity are protected, while allowing all parts of a connection to be authenticated.

Improved Performance: Using static Diffie-Hellman groups and Elliptic Curve (ECC) groups allows for faster handshaking than previous versions of TLS. Additionally, the use of 0-RTT data enables faster responses from web servers without compromising security or privacy, as an attacker does not have enough time to exploit vulnerabilities before responses are sent to clients.

Notable in the list of removals is the RSA key transport. This mode was mainly used because it was faster than Diffie ‑ Hellman, which required an additional round trip to establish the connection with Perfect Forward Secrecy (PFS). With TLS 1.3 the additional round trip is no longer necessary. With fewer configuration options, there is less information to exchange, and the Diffie ‑ Hellman handshake requires only one round trip to complete (the diagram also shows a GETrequired after handshake).

TLS HandShake

0-RTT or Resumption of the session (Zero Round Trip Time)

Additionally, TLS 1.3 supports the resumption of the session, which speeds up connection creation by eliminating the overhead of repeating the TLS handshake when a client returns to a previously visited site. This is also called 0 ‑ RTT reset (zero round trip time), because no handshake message has to go back and forth between client and server for the resumed session. Session resumption is implemented by creating a shared secret during the original session and storing it in a session ticket. When the client returns, it presents the session ticket along with its request, which is encrypted with the shared secret found in the ticket.

0-RTT NGINX

In short, Zero Round Trip Time Resumption or 0-RTT optimizes performance for clients that are resuming a connection to your site.

Technically, in Internet and network terminology, one occurs recovery when a client reuses known information from the handshake of a previously visited server.

Confused? Think of it this way (for example purposes only): let's say you are going to a new place for the first time, and it takes 15 minutes to get there (5 minutes of navigation setup + 10 minutes of travel). Now, when you go to the same place again, you will save 5 minutes because you already know the way and therefore you will not need navigation. The idea of ​​the recovery is similar.

Conclusion

TLS 1.3 is a big step forward in web performance and security. By combining TLS 1.3 with 0-RTT, the performance improvements are even more dramatic. Combine this with HTTP / 2 and the encrypted web has never been faster, especially on mobile networks. Feel free to consult us without obligation to find out once and for all the problems of your website that you do not yet know.

 

Do you have doubts? Don't know where to start? Contact us!

We have all the answers to your questions to help you make the right choice.

Chat with us

Chat directly with our presales support.

0256569681

Contact us by phone during office hours 9:30 - 19:30

Contact us online

Open a request directly in the contact area.

INFORMATION

Managed Server Srl is a leading Italian player in providing advanced GNU/Linux system solutions oriented towards high performance. With a low-cost and predictable subscription model, we ensure that our customers have access to advanced technologies in hosting, dedicated servers and cloud services. In addition to this, we offer systems consultancy on Linux systems and specialized maintenance in DBMS, IT Security, Cloud and much more. We stand out for our expertise in hosting leading Open Source CMS such as WordPress, WooCommerce, Drupal, Prestashop, Joomla, OpenCart and Magento, supported by a high-level support and consultancy service suitable for Public Administration, SMEs and any size.

Red Hat, Inc. owns the rights to Red Hat®, RHEL®, RedHat Linux®, and CentOS®; AlmaLinux™ is a trademark of AlmaLinux OS Foundation; Rocky Linux® is a registered trademark of the Rocky Linux Foundation; SUSE® is a registered trademark of SUSE LLC; Canonical Ltd. owns the rights to Ubuntu®; Software in the Public Interest, Inc. holds the rights to Debian®; Linus Torvalds holds the rights to Linux®; FreeBSD® is a registered trademark of The FreeBSD Foundation; NetBSD® is a registered trademark of The NetBSD Foundation; OpenBSD® is a registered trademark of Theo de Raadt. Oracle Corporation owns the rights to Oracle®, MySQL®, and MyRocks®; Percona® is a registered trademark of Percona LLC; MariaDB® is a registered trademark of MariaDB Corporation Ab; REDIS® is a registered trademark of Redis Labs Ltd. F5 Networks, Inc. owns the rights to NGINX® and NGINX Plus®; Varnish® is a registered trademark of Varnish Software AB. Adobe Inc. holds the rights to Magento®; PrestaShop® is a registered trademark of PrestaShop SA; OpenCart® is a registered trademark of OpenCart Limited. Automattic Inc. owns the rights to WordPress®, WooCommerce®, and JetPack®; Open Source Matters, Inc. owns the rights to Joomla®; Dries Buytaert holds the rights to Drupal®. Amazon Web Services, Inc. holds the rights to AWS®; Google LLC holds the rights to Google Cloud™ and Chrome™; Microsoft Corporation holds the rights to Microsoft®, Azure®, and Internet Explorer®; Mozilla Foundation owns the rights to Firefox®. Apache® is a registered trademark of The Apache Software Foundation; PHP® is a registered trademark of the PHP Group. CloudFlare® is a registered trademark of Cloudflare, Inc.; NETSCOUT® is a registered trademark of NETSCOUT Systems Inc.; ElasticSearch®, LogStash®, and Kibana® are registered trademarks of Elastic NV Hetzner Online GmbH owns the rights to Hetzner®; OVHcloud is a registered trademark of OVH Groupe SAS; cPanel®, LLC owns the rights to cPanel®; Plesk® is a registered trademark of Plesk International GmbH; Facebook, Inc. owns the rights to Facebook®. This site is not affiliated, sponsored or otherwise associated with any of the entities mentioned above and does not represent any of these entities in any way. All rights to the brands and product names mentioned are the property of their respective copyright holders. Any other trademarks mentioned belong to their registrants. MANAGED SERVER® is a trademark registered at European level by MANAGED SERVER SRL, Via Enzo Ferrari, 9, 62012 Civitanova Marche (MC), Italy.

JUST A MOMENT !

Would you like to see how your WooCommerce runs on our systems without having to migrate anything? 

Enter the address of your WooCommerce site and you will get a navigable demonstration, without having to do absolutely anything and completely free.

No thanks, my customers prefer the slow site.
Back to top