.

Site web rapide en HTTPS : les optimisations

TLS (Transport Layer Security) encrypts traffic to and from a web site, thereby preventing other parties from eavesdropping on your data. However, adding this safeguard to your web site introduces greater complexity and affects how the site interacts with your visitors. TLS can therefore slow down the loading of your web pages and affect user experience, but it is possible to remedy! Let's take a look at how Fasterize's optimizations and our CDN allow you to ensure both the security of your web site and your page speed in HTTPS.

End-to-end security: TLS 1.3 with Forward Secrecy

Encryption between browser and CDN

Connections between browser and our CDN are encrypted via TLS 1.3, with recent ciphers. As you can see it in the SSLLABS tests below, security level is at it’s maximum (A)

Test SSLLABS Level 1 - Sécurité TLS - HTTPS

This configuration of our CDN with TLS 1.3 is required to be compliant with PCI DSS standards, and we take care of updating ciphers suite used to encrypt communications.

Switching to a new cipher suite means that we are able to support the Forward Secrecy property for all browsers with TLS 1.3 capability. Using Forward Secrecy means that data encrypted today will remain private even if a communicating party's private key is compromised in the future. 

Encryption between CDN and our optimizations platform

Moreover, connection between our CDN and our optimizations platform is also encrypted with TLS 1.3.

Our platform supports a large choice of TLS versions and ciphers for origin connections. The validity of the certificate at the origin can also be ensured for any connection.

Now we’ve seen the encryption aspects, let’s move on to page speed and performance.

TLS session resumption

Fasterize implements re-usable TLS sessions, one of the most important mechanisms for improving web performance. The client can use a fast path when connecting by submitting a token provided by the server during the previous connection, thus reducing latency and computation time. 

 

Reprise de session TLS

There are two different mechanisms used to achieve this: session IDs and session tickets.

USING THE SESSION CACHE (SESSION IDS)

The browser stores the session ID and includes it in the "ClientHello" message during the subsequent TLS handshake. Fasterize then looks in its cache to find the session matching this ID and switches to a "fast path" handshake mechanism.

USING SESSION TICKETS

In the final data exchanged as part of a full handshake, Fasterize includes a "NewSessionTicket" message (not included in the handshake depicted above). This message includes the full TLS session state, including the shared secret and details of the encryption algorithms in use, all encrypted and protected by a key known only to Fasterize.

We thus reconcile security and speed … down to the smallest detail, even the least obvious.

OCSP Stapling

One lesser known issue affecting HTTPS performance is that of confirming the validity of certificates using the OCSP/CRL protocol. This validation step is performed by the browser and accounts for around 30% of the total overhead of using HTTPS. This is hugely significant!

But what is OCSP/CRL? They are the two protocols currently used to revoke TLS certificates. OCSP is preferred over CRL by modern browsers, as it requires less processing. The CRL protocol provides real-time certificate validation by querying the certification authority in question, on the basis of a whitelist (while CRL is based on a blacklist).

The main issue with OSCP is that the request is made by the browser. That validation request occurs in the middle of the critical rendering path.

OCSP Stapling

In other words, the browser waits for the response before continuing to process the page.

The idea of OCSP stapling is to shift the burden of making this request on to the server.

With OCSP stapling, the same server sending the certificate adds a message indicating that the certificate is valid, directly within the TLS response. Fasterize periodically queries the certification authority to update its certificate validation data. This information cannot be falsified, as the OCSP response is encrypted during the TLS handshake.

Now, let’s see the last mechanism behind our engine to secure and speed up HTTPS web pages.

TLS False Start

TLS False Start is an extension to the protocol, enabling the browser to send page data before the TLS handshake has completed. The browser does not alter the way in which it performs the TLS handshake, but modifies the point at which it begins to send encrypted data. To cut a long story short, TLS False Start allows TLS connections to be established in a single round trip.

 

TLS False Start

In practice, browsers will only enable this extension if the server supports the NPN/ALPN extension, which is enabled in Fasterize along with a cipher suite that supports Forward Secrecy, as explained above.

In short, Fasterize provides a significant speed-up to HTTPS websites by adding various optimizations at the TLS layer: 

  • a cipher suite supporting Forward Secrecy
  • OCSP Stapling
  • support for TLS session IDs and TLS session tickets,
  • along with support for TLS False Start

This will bring a significant benefit in terms of both user experience and SEO, as it will also ease Googlebot crawl.

You will then win on all fronts : security, UX, SEO and conversion rates!

Want to know more about what you could do
to speed up your HTTPS web site ? 

 

Discover our audit offer