Re-Hashed: Taking a Closer Look at the SSL/TLS Handshake
1 Star2 Stars3 Stars4 Stars5 Stars (8 votes, average: 5.00 out of 5)

Re-Hashed: Taking a Closer Look at the SSL/TLS Handshake

The TLS handshake sets up every HTTPS connection.

Let’s talk about the SSL handshake, or rather the TLS handshake as it’s now more accurately called. On the internet, SSL/TLS is the accepted solution for securing connections between a webserver and its visitors. You may not realize it, but you use SSL/TLS every day. If you see HTTPS and/or the padlock icon in your browser’s address bar, you have a secure connection with that site created by SSL/TLS.

In the last few years, SSL/TLS has gotten much more publicity and attention from the public and the I.T. industry as part of a larger focus on user security. Last year, 50% of all web traffic was encrypted with SSL/TLS for the first time. But many people still don’t really know how SSL/TLS works.

One of the most important parts of the SSL/TLS protocol is the SSL handshake, or TLS handshake (I’ll use them interchangably). The handshake is where each connection ‘begins’ and where the technical underpinnings of SSL/TLS are established.

To help you understand the TLS handshake process, we wrote two explanations. The next section explains the handshake broadly with minimal use of technical terms. The “Step by Step” section goes in-depth into the exact workings of the handshake.

 A Summary of the TLS Handshake

The ‘SSL handshake’ is the technical name of the process that establishes an HTTPS connection. Most of the hard work involved in the SSL/TLS protocol is done here.

An HTTPS connection involves two parties: the client (who is initiating the connection, usually your web browser), and the server. These two parties are the ones that ‘shake hands.’ The purpose of the SSL handshake is to perform all the cryptographic work needed to have a secure connection. This includes authenticating the SSL certificate being used and generating an encryption key.

[su_pullquote]The purpose of the SSL handshake is to perform all the cryptographic work needed to have a secure connection. [/su_pullquote]

Every piece of software is different. So the first steps of the TLS handshake have the client and server share their capabilities so that they can find the cryptographic features they mutually support.  Web browsers are the most common client, but features vary between popular browsers like Chrome, Firefox, Internet Explorer. Likewise, on the server side, popular operating systems like Windows Server, Apache, and NGINX have very different feature support.

Once a client and server agree on the exact encryption methods they will use, the server sends the client its SSL certificate. The client will check to make sure the certificate is “authentic” – this is an extremely important step. To truly have a secure connection, you can’t just encrypt your data, you also need to know it is being sent to the right person/place. SSL certificates provide that assurance.

SSL certificates are created and signed by a Certificate Authority (CAs), which are companies that have been approved to issue certificates. You likely know some of the most popular CAs like Symantec and Comodo. Those CAs follow industry standards to make sure that you can only get a certificate for a website or company you truly own.

During the TLS handshake, the client will perform cryptographically secure checks to make sure the certificate provided by the server is authentic. This includes checking the digital signature and making sure the certificate originates from a trusted CA.

The client will also get proof that the server owns the private key associated with the certificate. All SSL certificates contain a key pair consisting of a public and private key. The public key is used to encrypt data, and the private key is used to decrypt. This is known as “asymmetric” encryption because the two functions are performed by different keys.

With the most common type of key, RSA, the client will encrypt random data with the public key that needs to be used to generate the session key. The server will only be able to decrypt and use that data if it has the private key, which provides proof of possession. If another type of key is used this process changes, but proof of possession is always checked.

The last part of the TLS handshake involves creating the “session key” which is the key that will actually be used for secure communication. Session keys are “symmetric,” meaning the same key is used for encryption and decryption. These keys can achieve strong encryption much more efficiently than asymmetric keys, making them appropriate for sending data back and forth in an HTTPS connection.

To end the handshake, each party lets the other know they have done all the necessary work and then they both run checks to make sure the handshake occurred without any malicious tampering or corruption.

The entire SSL handshake takes places in a few hundred milliseconds. It’s the first thing that must happen in an HTTPS connection, even preceding the webpage loading.

Once the SSL handshake is complete, the encrypted and authenticated HTTPS connection begins and all the data being sent and received between you and the server is protected. Every time you revisit a site, the handshake will occur again. Many servers implement a “resumption” process for efficiency and speed.

The TLS Handshake: Step by Step

The handshake involves a series of steps, which accomplish the three main tasks we summarized above: exchanging encryption capabilities, authenticating the SSL certificate, and exchanging/generating a session key.

For those looking to understand the exact process, here are the steps involved[1]. Note that in TLS 1.3, the forthcoming protocol version, the handshake design has changed, thus these steps do not apply to TLS 1.3.

The steps are illustrated to show the client on the left and the server on the right.[2] Each step has a directional arrow in the middle to show who is receiving the message:

TLS Handshake

  1. The first message is the “ClientHello,” which is sent to the server. This message lists the client’s capabilities so that the server can pick how they will communicate.
  2. The server responds with the “SeverHello” message. In this message it tells the client what connection parameters it has selected from the provided list. If the client and server do not share any capabilities in common, the connection terminates unsuccessfully.
  3. In the “Certificate” message, the Server send’s its SSL certificate chain (which includes its leaf certificate and intermediate certificates) to the client. To provide authentication to the connection, which is as important as encryption, an SSL certificate is signed by a CA which allows the client to know the certificate is legitimate. The client will then perform checks to ensure the certificate is legitimate.[3] This includes checking the certificate’s digital signature, verifying the certificate chain, and checking for any other potential problems with the certificate data (expired certificate, wrong domain name, etc). The client will also make sure the server has possession of the certificate’s private key. This is done during the key exchange/generation process.
  4. This is an optional message, only needed for certain key exchange methods which require that the server provides additional data.
  5. The “Server Hello Done” message tells the client that it has sent over all its messages.
  6. The client then provides its contribution to the session key. The specifics of this step depend on the key exchange method that was decided on in the initial “Hello” messages. TLS uses two different keys: a public/private key pair (which is part of the SSL certificate), and a session key which is generated during the handshake. The session key is a “symmetric key.” It’s the key used during the HTTPS connection because its significantly faster and more efficient that using the public/private key pair, which is “asymmetric” and inherently slower. The public/private key is only used during these steps for the secure transmission of the session key.
  7. The “Change Cipher Spec” message lets the other party know that it has generated the session key and is going to switch to encrypted communication.
  8. The “Finished” message is then sent to indicate that the handshake is complete. The Finished message is encrypted, and is the first data protected by the session key. The message contains data that allows each party to make sure the handshake was not tampered with.
  9. Now it’s the server’s turn to do the same. It sends its “Change Cipher Spec” message to indicate it is switching to encrypted communication.
  10. The server sends its “Finished” message.

After these steps the SSL handshake is complete. Both parties now have a session key and will begin to communicate with an encrypted and authenticated connection. At this point, the first bytes of “application” data (the data belonging to the actual service the two parties will communicate about – i.e. the website’s HTML, Javascript, etc) can be sent.

[1] Note we are only covering a typical handshake where only server authentication is involved. In TLS it is possible to have mutual authentication, where the client also provides a certificate. However this is rarely used.

[2] References: Section 7 & 7.4 of the TLS 1.2 RFC. Chapter 2 of Bulletproof SSL & TLS by Ivan Ristic.

[3] Note, the TLS RFC specifies the certificate verification should happen after the ServerHelloDone message.

    • Hi Rahil,

      Overall, TLS 1.3 has a *ton* of changes. It is hard to summarize them all in one comment. Was there something specific you wanted to know about TLS 1.3?

      One of the biggest differences is the introduction of zero round-trip handshakes which can greatly speed up the HTTPS connection process. The handshake itself has been overhauled as well, and you can see the steps here in the official doc:

      That doc can be a bit dense, so we will be doing an article in the future breaking down the TLS 1.3 handshake the way we have done here with TLS 1.2.

      Another major change in TLS 1.3 is that a ton of the outdated and confusing encryption options have been removed. This will greatly reduce the chance of an insecure configuration as well as reduce the attack surface.

  • Thanks. This is a great explanation of SSL handshakes. One of the important issues, which you touch on, is the impact of SSL handshakes and speed, as they do slow things down – taking several Round Trip Time. This is an area that a CDN can help to speed things up while also ensuring security (both because of the use of SSL/TLS encryption and also if the CDN is also paired with a WAF).

  • You state that “All SSL certificates contain a key pair consisting of a public and private key”. This is incorrect. The SSL certificate only contains the digitally signed public key. The public key is used to encrypt the pre-master secret, so it’s authenticity is critical in ensuring secure communication. If the certificate also contains the private key it would defeat the whole purpose of the SSL process. As its name implies the private key should remain absolutely private and never be compromised.

    • Hi Gary,

      Thanks for pointing that mistake out! I meant to say that there is a key pair associated with each certificate. I will re-word that.

  • I have seen Handshake expressed differently.
    Does the client always get the server’s “Cipher Spec” first?
    Is there a case where a client first sends a “Cipher Spec” to the server?

    Thank you for always good posts.

Leave a Reply

Your email address will not be published. Required fields are marked *

Captcha *


Vincent Lynch

The SSL Store’s encryption expert makes even the most complex topics approachable and relatable.