TLS (Transport Layer Security) encrypts a website’s traffic, preventing other entities from intercepting, monitoring and modifying its communications. However, the addition of this protection introduces a certain complexity into exchanges between server and browser. TLS can therefore slow down the loading of your web pages and affect the user experience, but this can be remedied! Let’s take a look at how Fasterize and its CDN optimizations can ensure both the security of your site and the speed of your HTTPS pages.
End-to-end security: TLS 1.3 with Forward Secrecy
Browser-to-CDN security
Our connections between the browser and our CDN are secured via TLS 1.3, with recent ciphers . As you can see from the results of this SSLLABS test, the security level is at the maximum (A).
This configuration of our CDN with TLS 1.3 is necessary to comply with PCI DSS standards, and we regularly update the suite of ciphers used to encrypt communications.
The cipher suite ensures Forward Secrecy for all browsers supporting the TLS 1.3 protocol. Forward Secrecy ensures that encrypted information remains confidential if a correspondent’s private key is compromised.
Secure connection between CDN and our optimization platform
The connection between the CDN and our optimization platform is also secured using TLS 1.3.
Our platform supports a wide range of TLS and cipher versions for connecting to your origin. The validity of the certificate at origin can also be assured for any connection.
Now that we’ve seen the safety aspects, let’s move on to the speed and performance aspects.
TLS session recovery
Fasterize ensures the resumption of TLS sessions, an essential technique for improving performance. The client can avoid a complete negotiation by presenting the details of the previous negotiation directly to the server. This reduces latency and computation times.
This time-saving is made possible by two mechanisms: session identifiers and session tickets.
USE OF SESSION CACHE (SESSION IDENTIFIERS)
The browser stores the session identifier and presents it in the “Client Hello” message during the next TLS handshake. Fasterize then consults its cache to find the session corresponding to this identifier and proceeds with the TLS negotiation, which is then shortened.
USE OF SESSION TICKETS
In the last exchange of a complete handshake, Fasterize includes a “New Session Ticket” message (not shown in the handshake illustrated above). This message contains the complete status of the TLS session, including the shared secret and the encryption algorithms to be used, all protected by a key known only to Fasterize.
That’s how we reconcile safety and speed… right down to the smallest details, even the least obvious.
OCSP Stapling
One of the lesser-known problems affecting the performance of an HTTPS site is the time needed to check the validity of certificates using the OCSP/CRL protocol, known as OCSP Stapling.
This verification by the browser accounts for around 30% of the total HTTPS overhead in terms of loading speed. That’s a lot!
But what is OCSP/CRL? These are two TLS certificate revocation protocols. OCSP is preferred by modern browsers to CRL because it is simpler to process. It allows you to check the validity of a certificate in real time by querying the certification authority, based on a white list (unlike CRL, which relies on a black list).
The main problem with OSCP is that this request is made by the browser, and lies on the critical path of page rendering.
In other words, the browser waits for the response to continue processing the page, and until it receives it, rendering is blocked.
The idea behindOCSP Stapling is to entrust the processing of this request not to the browser, but to the server.
In this way, the server that sent the certificate adds (“staples”) the indication of the certificate’s validity directly into the TLS response. Fasterize periodically requests the certificate authority to update the validity information – information that cannot be falsified, since the OCSP response is encrypted during the TLS handshake.
Now let’s take a look at the latest technique behind our engine for securing and accelerating HTTPS pages.
TLS False Start
TLS False Start is a protocol extension that allows the browser to send page data before the end of the TLS handshake. It does not modify the TLS handshake, but changes the start of the encrypted data transmission. In short, TLS False Start means that new TLS connections can be established with just one round-trip.
In practice, browsers only use this extension if the server supports the TLS NPN/ALPN extension. And this is precisely what is enabled on Fasterize, along with a cipher suite supporting Forward Secrecy, as we saw earlier.
In short, Fasterie enables you to speed up your HTTPS site considerably, by optimizing the TLS layer with various techniques:
- a suite of ciphers managing Forward Secrecy,
- OCSP Stapling,
- support for TLS session identifiers and TLS session tickets,
- and TLS False Start.
All these optimizations not only improve the speed of your site as perceived by your users, but also facilitate the Google crawl , thus contributing to better referencing. You win on all fronts: security, UX and SEO, and therefore conversion rates!
