These days, most people with a website probably know about the importance of using an SSL certificate for added security, but chances are they don't know what’s going on behind the scenes. Even if you've heard mention of secure connections and encryption, do you actually know what that means or how it's achieved? If not, you've come to the right place.

Today we're going to take an in-depth look at SSL encryption, first discussing what encryption is, how it relates to SSL, and what happens every time you connect to a website or application with an SSL certificate.

What Is Encryption?

Let's start with the basics: encryption is the process of converting data into an unreadable code, for instance, a message containing sensitive information. It ensures that only authorized parties can read the message (the sender and recipient), and will not be understood if it is intercepted by a third-party. 

What Is SSL Encryption?

With SSL encryption, data sent between a client and a server is encrypted. One of the most common, everyday examples of this is a web browser (client) and a website (server). An SSL certificate creates a secure connection making it so only the browser and website can understand messages sent over their connection and not anyone who tries to intercept the message while it's in transit.

It does this through cryptographic algorithms that use special keys. A cryptographic key is basically a string of characters that scrambles plaintext information so that it is unreadable and vice versa. An SSL certificate ensures that only those with the right key can decode the information. Think of a physical, locked door that can only be locked and unlocked with a particular key. Data sent over an SSL-secured connection can only be encrypted and decrypted using a specific cryptographic key.

How does an SSL certificate do this?

The next section will deal with the nitty-gritty of everything that happens behind the scenes, but right now we're going to focus on what makes SSL encryption possible: the TLS protocol.

Short for Transport Layer Security, TLS is the protocol that ensures websites load via a secure HTTPS connection. There have been many iterations and versions of TLS over the years, the latest of which is TLS 1.3.

When a browser attempts to connect to a website that has an SSL certificate installed, the SSL certificate ensures that the connection is established over the HTTPS (Hypertext Transfer Protocol Secure) protocol rather than the less secure HTTP (Hypertext Transfer Protocol). HTTP is the protocol used across the web to connect websites to each other and transfer data. The TLS protocol is what encrypts this connection and makes it secure (thus the “S” at the end of HTTPS).

Not only does TLS protect information exchanged over this connection, but it also authenticates the SSL, checks its validity period, and that it was issued by a trusted CA (Certificate Authority).

All this happens through something known as the SSL (or TLS) handshake.

The SSL handshake

The SSL handshake takes place as soon as a browser attempts to connect to a website. It’s essentially how both exchange cryptographic data. There are multiple steps involved in this process, with the two exchanging a series of messages with information about how to proceed while also authenticating each other.

How the SSL handshake plays out is dependent on the version of TLS being used. As we mentioned previously, the latest version is TLS 1.3, which has shortened the process by a few milliseconds, has fewer steps and is less vulnerable to attack than the previous version, TLS 1.2. Since TLS 1.2 is being phased out, and TLS 1.3 is becoming more widely adopted, we’ll be focusing on the TLS 1.3 handshake today. 

Before we talk about the process, we need to explain a couple of key terms that will help you understand it a little more: Cipher Suites and Key Exchange. 

Cipher Suites 

A cipher suite is a set of algorithms that perform a cryptographic function. In this case, encrypting a network connection using the TLS protocol. In plain English, it provides the rules as well as the order of steps that must be followed to establish a secure connection. 

When a client connects to a server, they establish which cipher suites are supported by both, and agree on one that will be used to carry out the process. With TLS 1.3, there are currently five possible cipher suites that can be used. The algorithms usually included in a cipher suite are a key exchange algorithm, a bulk encryption algorithm, and a message authentication algorithm. 

Let's zero in on key exchange.

Key Exchange

For the client and server to authenticate each other and establish a secure connection there needs to be an exchange of keys. Doing this in a secure manner is known as public-key cryptography. We briefly touched on keys earlier and how they're used to encrypt and decrypt data. Public-key cryptography (also known as asymmetric cryptography) uses two different but related keys to encrypt and decrypt data. These keys are called the public key and the private key. (You can find a really good analogy for the process here.)

TLS 1.3 supports a form of public-key cryptography known as Diffie-Hellman. There are many different parameters for Diffie-Helman, and while TLS 1.2 could use any version, TLS 1.3 only allows use of only the most secure parameters. 

In the most simple terms, with Diffie-Hellman, both the server and the client generate a public-private key pair by using modular arithmetic. They exchange the public parts of these key pairs. They then combine the public key received from one another to their own private key and both the client and server should end up with the same value. This value is the session key. This is a temporary key, which encrypts all the messages sent between a client and a server in a single session. 

The SSL Handshake in Three Steps

Now that you have a better idea of the meaning behind some terminology, here is what happens during the SSL handshake:

1. The client begins the process by sending a "Client Hello" message to the server. It also sends a list of Cipher Suites that it supports, while also guessing which Diffie-Hellman parameters the server will use and sends its newly generated public key. 
2. The server replies by sending a "Server Hello" message to the client. It also sends its chosen Diffie-Hellman parameters, its own new public key, as well as its SSL certificate, and a "Server Finished" message.
3. The browser then checks the server's SSL and generates keys with the public key share that the server sent along. Once done, it sends a "Client Finished" message. After this, encryption begins. 

Wrap Up

Hopefully now you have a better understanding of what encryption actually does and how it works behind the scenes. If you want to secure your site with an SSL certificate, check out the range of affordable options we have to offer.