How SSL/TLS Handshake Works

SSL/TLS Handshake is a "handshake" between the server and the client. Simply put, it's about identifying each other. It occurs during an HTTPS connection inside an SSL/TLS encrypted tunnel, which guarantees the security of both the server and the client. After successful identification, a secret session key is generated that ensures secure communication – it serves to both encrypt and decrypt the data being transmitted.

Data encryption

The handshake process is necessarily accompanied by an exchange of information about the supported cryptographic technologies – this is necessary so that the server and the client agree on the best cipher suite for both parties. After the agreement, the server transfers its SSL certificate to the client.

Symmetric encryption prevents third parties from reading the data. In addition, even if packets are intercepted, they cannot be altered because each message contains a MAC code that verifies the integrity of the data.

How SSL/TLS handshake works

If you imagine SSL handshaking as a dialog between the server and the client, the process will look like this

1. The client asks the server to establish a secure connection and offers a set of ciphers that it "understands", as well as a compatible version of SSL/TLS.
2. The server checks the cipher suite sent, compares it to its own, and sends a response to the client with a certificate file and public key.
3. The client checks the certificate and, if everything is OK, offers to check the private key. To do this, it generates it and encrypts the shared secret key with the server's public key sent earlier.
4. The server accepts the key and verifies it with its private key. Then it creates a master secret, which will be used to encrypt the exchanged information.

After that, the client sends a test message to the server, encrypted using a previously thought-out method, and the server decrypts and analyzes it. This completes the SSL/TLS Handshake, and the client and the server can exchange information in peace.

If the session is terminated and the client contacts the server again some time later, the handshake procedure will not require going through the same procedure all over again – all previously generated data and the main secret will remain valid. The whole process takes a few seconds and goes completely unnoticed by the user.



Diffie-Hellman algorithm in TLS Handshake 1.2

Version 1.2 of the TLS protocol appeared in 2008 as a major update of the 1.1 protocol with an improved mechanism for reconciling parties to lists of supported encryption methods. It looks as follows:

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

Here:

• TLS – data transfer protocol;
• ECDHE – temporary (ephemeral) key;
• ECDSA – authentication algorithm;
• AES 128 GCM – symmetric encryption algorithm;
• SHA256 – data hashing algorithm.

This is the Diffie-Hellman algorithm, but today it is considered outdated and rarely used.

TLS Cipher Suites 1.3

This version of the protocol saw the light of day in 2018 and has undergone a number of significant improvements:

• key negotiation processes, authentications, and encryption sets have been separated;
• a rule stating that digital signatures are mandatory was added;
• HKDF key retrieval function was implemented;
• connection processes were accelerated;
• data compression, unauthenticated message ciphers, and renegotiation, which provided some vulnerability to the previous version of the protocol, are prohibited;
• ChaCha20 stream cipher with Poly1305 MAC code, efficient Ed25519 and Ed448 digital signature algorithms, and their corresponding Curve25519 and Curve448 key exchange protocols were added.

The TLS 1.3 handshake cipher  suite looks like this:

TLS_AES_256_GCM_SHA384

Accordingly, here are:

• TLS protocol;
• AES-256 in GCM mode – encryption and authentication algorithm with additional data (AEAD);
• SHA384 – hash key generation function (HKFD) algorithm.

TLS 1.3 protocol has undergone a huge number of changes and improvements, which had a positive impact on the security and performance of Handshake processes, and authentication itself takes much less time. Handshake speed has almost doubled, and the protocol has lost several vulnerabilities that previously caused a lot of problems for system administrators.

Conclusion

The most secure option is the TLS 1.3 cryptographic protocol, but it has specific backward compatibility. When establishing a connection, the client and server exchange versions of the protocol and choose the one that both parties can work with. But in practice, it turned out that a number of servers on the old TLS 1.2 protocol instantly cut the connection if the "handshake" should take place through the TLS 1.3 protocol. This phenomenon was called ossification, and it caused problems in the early years with the introduction of the new protocol. Today, this problem does not occur almost anywhere, and the servers themselves have mostly switched to TLS 1.3, so we recommend using it.