HTTPS 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 lead to slow page loading times and have a negative impact on user experience. In this article, we introduce the various optimisations implemented by Fasterize at the TLS security layer to ensure your web site remains slick while maximising security.

HTTP and HTTPS requests
NB: There are a number of best practices when it comes to correctly configuring your server to use HTTPS. These best practices come ready enabled for all web sites running through Fasterize and we strive to update our server configuration on a regular basis to ensure PCI-DSS compliance.

Improved security: SSL3 dropped in favour of TLS 1.2 and Forward Secrecy

In January 2015, we conducted a security audit of our TLS connectivity. The end goal was to obtain a maximum "A" security rating on the SSLLABS test.

Capture d’écran 2015-03-02 à 18.31.26

Fasterize disabled support for the SSL3 protocol in June 2014. Since then, the SSL3 protocol has been deemed to be insecure. By continually updating the version of OpenSSL used on our servers, we offer customers protection from known attacks: HEARTBLEED, CRIME, BEAST attack, etc.

Following the audit, we reviewed the cipher suite used to encrypt communications.

Switching to a new cipher suite meant that we were able to support the Forward Secrecy property for all browsers with TLS 1.2 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. More information on Forward Secrecy can be found on the Internet.

2017: The arrival of TLS 1.3

TLS 1.3 is not yet finalised. But we know that this major revision will offer two key advantages over previous versions:

  • Enhanced security
  • Faster performance

More info

TLS session resumption

Fasterize implements re-usable TLS sessions, one of the most important mechanisms for improving TLS 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. 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.

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!

OCSP/CRL 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.
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.


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.

TLS false start

TLS False Start is a 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.

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


Fasterize provides a significant speed-up to HTTPS web sites by adding various optimisations 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.

Our next step will be to enable the full suite of front-end optimisations for web pages served over HTTPS.


Looking to boost the speed of your web site over HTTPS?

See our plans

Hello SMX Paris !