Transport Layer Security (TLS) is a cryptographic communication protocol primarily used in the authentication and encryption of application data over the Internet1. Most notably, TLS is used in the transmission of HTTP messages using a protocol called HTTP Secure (HTTPS).

HTTPS originally referred to HTTP over Secure Socket Layer (SSL), but SSL was renamed to TLS following version 3. Although SSL is now deprecated, the terms SSL and TLS are often used interchangeably2.

TLS 1.2

The following is a typical TLS 1.2 handshake sequence:

  1. Client sends “ClientHello” message. Includes supported TLS versions, supported cipher suites, and random number to initialize various cryptographic parameters (i.e. client nonce)3.

  2. Server sends “ServerHello” message. Includes chosen TLS version, chosen cipher suite, and server nonce.

  3. Server sends “Certificate” message. This is the server’s public key digital certificate.

  4. Server sends “ServerKeyExchange” message. For example, this could include the Diffie-Hellman parameters, the server’s Diffie-Hellman public key, and a corresponding digital signature computed using these values.

  5. Client has enough information to perform a Diffie-Hellman key exchange. Client verifies the identity of the server by checking its digital certificate against its digital signature. If client is happy, sends back “ClientKeyExchange” message containing their own Diffie-Hellman public key4.

  6. At this stage, both client and server have each other’s Diffie-Hellman public keys. They each calculate the same pre-master secret and with that they have enough information to begin encryption. The client now sends a “ChangeCipherSpec” message that tells the server that the next message will be encrypted.

  7. The client sends a “Finished” message that is an encrypted message containing a MAC which has been calculated over all prior messages to ensure nothing has been tampered with.

  8. The server attempts to decrypt and verify the client’s “Finished” message. If successful, the server sends its own “ChangeCipherSpec” message to the client.

  9. The server sends an encrypted “Finished” message containing a MAC which has been calculated over all prior messages. If everything has gone well, the server’s “Finished” message is identical to the client’s “Finished” message (once decrypted) because both hashes have been calculated over the same prior messages.

TLS 1.2

The client then decrypts and verifies the server’s “Finished” message and, if successful, all future messages between client and server will be encrypted.

Notice it took two round trips (2-RTT) of messages between client and server to complete the handshake sequence. Timing is important because a handshake needs to be performed every time we visit a website with HTTPS.

TLS 1.3

TLS 1.3 was defined in August 2018 and it significantly improves the security and performance of TLS 1.2. The following is a typical TLS 1.3 handshake sequence:

  1. Client sends “ClientHello” message. Includes supported TLS versions, supported cipher suites, and client nonce.

  2. Client sends “ClientKeyShare”“ message. Includes a set of Diffie-Hellman parameters and public keys that may be used in the key exchange.

  3. Server sends “ServerHello” message. Includes chosen TLS version, chosen cipher suite, and server nonce.

  4. Server sends “ServerKeyShare” message. Includes public key for key exchange.

  5. Server sends “Certificate” message. Includes the server’s public key digital certificate.

  6. Server sends “Finished” message. Contains MAC calculated over prior messages.

TLS 1.3

Improvements over TLS 1.2

  • reduced the number of round trips between client and server from two to one (1-RTT)
  • removed support for legacy encryption and authentication algorithms in favour of AEAD
  • removed support for RSA public-key cryptography in favour of Perfect Forward Secrecy
  • added support for the encryption of all handshake messages following “ServerHello”5
  • added support for zero round-trip time (0-RTT) mode6



  1. While encrypting HTTP messages is its most famous use-case, TLS can be used in other applications just as well (e.g. inter-application communication). ↩

  2. Part of the reason we still use these terms interchageably is to maintain compatibility with code libraries that historically relied on SSL to enable HTTPS. ↩

  3. Cipher suite refers to the combination of algorithms used in the authentication and encryption of messages (e.g. RSA, DH-KEX, AES-GCM, etc.). ↩

  4. At this stage the client could also send back its public key digital certificate for verification by the server; but this is not common practice in most applications. ↩

  5. The most notable benefit of this is that it allows for the encryption of the server’s digital certificate. ↩

  6. 0-RTT mode allows the client to use a previously shared key to authenticate the server and encrypt application data in its first message, effectively allowing it to skip the handshake sequence for session resumptions. The use of this mode could break forward secrecy and present a vulnerability to replay attacks if proper precautions are not taken. ↩