Home > Learning Center > Performance > Secure Sockets Layer/Transport Layer Security (SSL/TLS) 

Secure Sockets Layer/Transport Layer Security (SSL/TLS)


What is SSL/TLS

Secure Sockets Layer (SSL) and its successor, Transport Layer Security (TLS) are protocols that provide private, encrypted communication across networks.

The benefits of an SSL/TLS connection include:

  • Privacy – Communication between two connected networks is secured by a unique key that can’t be obtained by a third party.
  • Authentication – The identity of the communicating parties is verified using a public-key cryptogram.
  • Integrity – An authentication algorithm determines whether a message has been altered.

Transport layer security was released in 1999 as an updated version of SSL. The protocol has been shown to plug certain vulnerabilities in SSL 3.0, including those exploited in the 2014 POODLE attack in which attackers decrypted and extracted information from inside an encrypted transaction.

SSL/TLS Certificates

An SSL/TLS certificate is a data file that encrypts information sent to a server and authenticates the identity of a website. Applications, browsers and operating systems maintain a list of root certificates provided by a trusted Certificate Authority (CA).

There are several types of SSL/TLS certificates, including single-name certificates that protect one subdomain, wildcard certificates that protect unlimited subdomains, and multi-domain certificates. There are two forms of multi-domain certificates:

  • Subject Alternative Name (SAN) – SAN allows identities, such as an email address, DNS name, IP or URL to be bound to the subject of a certificate. This provides the ability to secure multiple domains with a single certificate.
  • Unified Communications Certificate (UCC) – UCC protects the Microsoft Exchange Server and Office Communications Server, allowing them to connect with multiple web services securely.

Yet another type of SSL certificate is Extended Validation (EV). EV certificates reassure users that they are viewing a website that is owned by the legal entity that purchased the SSL certificate, not an impostor site. The user’s browser displays a green address bar containing the name of the legal entity to confirm the site’s validity.

An example of an EV certificate

EV certificate example

Each SSL/TLS certificate has to be hosted on a unique IP address. Because CDNs aren’t able to allocate a standalone IP for every website using their service, multi-domain certificates are typically used.

However, many CDNs offer premium features that enable the customer to rent an individual IP address, which is especially useful for an organization that wants to use their own custom/EV certificates.

SSL Handshake

For an SSL/TLS connection to be established, the following process must take place:

  1. At the TCP layer, the client sends a SYN (synchronize) packet to the server.
  2. The server sends a SYN-ACK (synchronize-acknowledge) packet back to the client.
  3. The server sends an ACK (acknowledge) packet to the server. Together with the ACK packet, an SSL/TLS client also sends a client hello message that includes cryptographic algorithms (cipher suites) and a random byte string.
  4. The server responds with a ServerHello message containing the chosen cipher suite, a session ID, digital certificate and another random byte string. If required, the server issues a client certificate request containing the supported certificate types and CA names.
  5. The client verifies the server’s certificate, and then sends a ClientKeyExchange – the random byte string used to create an encryption key. If necessary, the client also provides a private key and its own client certificate, or a warning that no certificate exists. Lastly the client sends a ChangeCipherSpec message to say that from here on, communication will be encrypted using the negotiated key and cipher suite.
  6. The server responds with a ChangeCipherSpec message to confirm.
  7. The client and server can now exchange requests and responses for the duration of the session. The messages are symmetrically encrypted by the secret key.

An SSL handshake establishes an SSL/TLS connection between client and server

The Benefits of Using CDNs with SSL/TLS

When a secure socket layer client connects to your website via a CDN, the SSL handshake occurs between the client and the CDN proxy server – not the origin server hosting your site.

In parallel, a second encrypted communication channel is open between CDN and your origin.

Using a CDN speeds up the SSL handshake

Using the CDN to service SSL/TLS traffic has the following advantages:

Better Performance

A CDN reduces the round trip time (RTT) experienced by your users, because they interact with a local CDN proxy server and not directly with your (likely more remotely located) origin.

This has significant benefits for the speed at which a transport layer security session can be established, since the TLS/SSL handshake involves six exchanges, equal to three times the user’s RTT.

For example, a CDN that reduces RTT from 50ms to 20ms will reduce the TLS handshake time from 150ms (three times the RTT) to just 60ms, (as seen in the image below).

In addition, CDNs use optimized settings, such as False Start and Session Resumption to improve performance.

Using a CDN with SSL/TLS accelerates performance and reduces RTT

Better Security

When using a CDN, the user’s SSL/TLS client connects to the CDN’s SSL certificate, not your own certificate. A CDN’s certificate is usually of the highest grade, i.e., A+.

This means that using a CDN will provide your users with the highest level of SSL security, regardless of the certificate that’s being used on your origin server.

In addition, using a CDN is an easy way to enforce HTTP Strict Transport Security (HSTS) — a security mechanism that enables easy site-wide TLS protection.