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.
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.
If you imagine SSL handshaking as a dialog between the server and the client, the process will look like this
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.
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:
This is the Diffie-Hellman algorithm, but today it is considered outdated and rarely used.
This version of the protocol saw the light of day in 2018 and has undergone a number of significant improvements:
The TLS 1.3 handshake cipher suite looks like this:
Accordingly, here are:
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.
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.