SSL Handshake (TLS Handshake) Explained

Updated: 09/18/2024 - 1:40

Time to read: 4 minutes

An SSL handshake defines a connection between two devices, such as your browser and the server that supports the website you want to visit.

During an SSL handshake, the two devices determine:

What security version both parties will use
What type of encryption will protect the information
How both parties are verified

The word "SSL" in SSL handshake is a misnomer. The secure sockets layer (SSL) protocol is old, and people rarely use it these days. Now, most devices use transport layer security (TLS).

The term “TLS handshake” is more accurate, but it’s common for people to call this step a simple SSL handshake instead.

What is an SSL handshake?

Pull up a website on your browser, and you may believe the connection happened both instantly and spontaneously. In reality, the two devices need to negotiate how they'll communicate and transfer information. That negotiation happens through an SSL handshake.

As we mentioned, the SSL handshake is sometimes called the TLS handshake. Here's why.

Netscape developed the SSL protocol in 1995. Unfortunately, it was riddled with security flaws. In the early 2000s, the industry moved to the TLS protocol for the promise of better security. The handshake process remains the same despite the name change.

An SSL handshake is a process that begins a communication session. The two parties acknowledge one another, determine how they will protect information, verify one another's security protocols, and set session keys.

SSL handshake steps explained

As we've explained, SSL handshakes are negotiations. The two parties agree on styles and protocols. The SSL handshake steps result from those agreements, and they can vary depending on what the two sides want.

In general, an SSL handshake proceeds via these steps:

Contact: A browser sends a "client hello" message to the server. The message includes critical details, such as the SSL version the client uses, cipher settings (more on that in a minute), and session-specific information.
First response: The server sends back proof of security (via certificates), the server's cipher settings, and session-specific data.
Authentication: The browser verifies the security certificate to ensure it made contact with the right authority.
Key exchange: The browser and the server exchange keys, validating the security of their exchange.
Wrap up: Both the server and the browser confirm that the work is complete, and the handshake is finished.

Despite the complexity of these steps, it takes just a few seconds for both sides to do their work. Few users notice the delay.

How secure is an SSL/TLS handshake?

Look through the SSL handshake steps, and you'll notice a mention of key exchange. That process involves encryption, and the process uses two forms.

The two forms of encryption include:

Asymmetric encryption. A public key, readily available via the server's security certificate, is used for description. A private key is used for decryption.
Symmetric encryption. After asymmetric encryption, the two parties set up a shared key. This single session key allows for a secure connection with lower server strain.

The two parties also agree on a so-called "cipher suite," a set of rules about what type of authentication will be required, how they'll encrypt data, and more.

These steps should protect data in transit. But unfortunately, attacks are still possible. The BREACH attack, for example, allows hackers to change data in transport. Hackers can also take over and perform a man-in-the-middle attack. The problem begins with data that attackers steal as it's encrypted.

Many security experts became aware of security risks with encryption in 2012, when news of vulnerable Android apps broke. Did you miss the story? Read our recap here.