💾 Archived View for gemini.susa.net › gen › SSL_Handshake_explained.gmi captured on 2021-12-05 at 23:47:19. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-11-30)
-=-=-=-=-=-=-
Kasun_Dharmadasa_(Image)[1][2]
If you have ever browsed an HTTPS URL through a browser, you have experienced the SSL handshake. Even though might not notice it, the browser and the website is creating an HTTPS connection using one-way SSL handshake.
The main purpose of an SSL handshake is to provide privacy and data integrity for communication between a server and a client. During the Handshake, server and client will exchange important information required to establish a secure connection.
There are two types of SSL handshakes described as one-way SSL and two-way SSL (Mutual SSL). The difference between those two is that in one -way SSL, only the client validates the identity of the server whereas in two-way SSL, both server and client validate the identity of each other. Usually, when we browse an HTTPS website, one-way SSL is being used where only our browser (client) validates the identity of the website (server). Two-way SSL is mostly used in server to server communication where both parties need to validate the identity of each other.
During an SSL handshake, the server and the client follow the below set of steps.
1. Client Hello
The client will send the information that will be required by the server to start an HTTPS connection.
In the above log, we can see that the client hello with TLS v1.2. By this, the client notifies the server that it has the support for TLS[1] versions 1.2 and below. List of ciphers[2] that are supported by the client can also be seen from the above log. Out of this list, the server will select a cipher suite that it supports. If the list contains cipher suites that server does not recognize, support, or wish to use, the server will ignore those ciphers. If no supported cipher suites were found the server will send a failure alert and close the connection.
2. Server Hello
The server will respond back with the configuration it selected from the Client Hello along with its information to proceed with the handshake. Server Hello will be as follows.
Sever will select the TLS version according to the lower of that suggested by the client in the Client Hello message and the highest supported by the server. The server will also send back the cipher suite it selected from the list of ciphers presented by the client.
Along with the Server Hello, the server will also send the certificate[3] of the server with the certificate chain. The certificate chain will be validated against the certificates in the client trust store[4].
3. Server Key Exchange Message
This message will be sent by the server to the client carrying the required details for the client to generate the pre-master secret. This message will not be sent if RSA key exchange algorithm (more in this later) or any other key exchange algorithms are used that do not require the information from the server to generate a pre-master secret.
For Elliptic Curve Diffie Hellman(ECDH)[5] key exchange, the following details on the server ECDH public key are being sent to the client.
4. Certificate Request
This is the place where one-way SSL defers from two-way SSL. In one-way SSL, the authenticity of the client is not being validated. Hence, this step is omitted in one-way SSL handshake.
During this step, the server will send a certificate request from the client with the certificate type, certificate signature algorithms and certificate authorities [6] supported by the server. There can be situations where the certificate authorities list can be empty. In such scenarios, the client may choose whether to send or avoid sending of the client certificate (depends on the client implementation)
Finally, the server sends the Server Hello Done message indicating the end of Server Hello. After sending this message, the server will wait for a client response.
5. Client Certificate
The client presents its certificate chain to the server. The certificate needs to be appropriate for the negotiated cipher suite’s key exchange algorithm, and any negotiated extensions.
6. Client Key Exchange Message
This message needs to be sent by the client following the Client Certificate message. If the client certificate is not being presented (in one-way SSL), the client key exchange message should be sent after the client receives the ServerHelloDone message.
As we all know the data transferred between the server and the client in an HTTPS connection will be encrypted. Symmetric encryption[7] is being used for this purpose as the computational cost is much lower than Asymmetric encryption. In order to use symmetric encryption, there needs to be a common key between the two ends. The purpose of this message is to generate that common key between that client and the server without exposing to an outsider.
There are two client key exchange methods described in the TLS v1.2 spec. They are RSA[8] and Diffie-Hellman.
If RSA is used as the key exchange algorithm, the client generates a 48-byte pre-master secret. The client encrypts the pre-master secret by the public key of the certificate and sends to the server. Only the server will have the corresponding private key to decrypt and get the client generated pre-master secret.
If Diffie-Hellman is used, the Diffie-Hellman parameters are transmitted to allow both client and server to generate the same pre-master secret.
After that, both sides will generate a master secret using the pre-master secret and the master secret will be used to generate the symmetric key for encrypting the session data
7. Finished
After successful authentication and generating the pre-master secrets/master secrets, a change cipher spec message will be sent by both client and server indicating that the rest of the communication will be encrypted.
The Finished message will immediately follow the change cipher spec message. This will be the first message encrypted with the negotiated algorithms. Application data will be transferred only after both parties send the finished message and verifying the content of the message.
[1] https://tools.ietf.org/html/rfc5246[3]
[2] https://docs.microsoft.com/en-us/windows/desktop/secauthn/cipher-suites-in-schannel[4]
[3] https://www.websecurity.symantec.com/security-topics/what-is-ssl-tls-https[5]
[4] https://docs.apigee.com/api-platform/system-administration/keystores-and-truststores[6]
[5] https://wiki.openssl.org/index.php/Elliptic_Curve_Diffie_Hellman[7]
[6] https://www.globalsign.com/en/ssl-information-center/what-are-certification-authorities-trust-hierarchies/[8]
[7] https://www.ssl2buy.com/wiki/symmetric-vs-asymmetric-encryption-what-are-differences[9]
[8] https://www.geeksforgeeks.org/rsa-algorithm-cryptography/[10]
[9] https://www.acunetix.com/blog/articles/establishing-tls-ssl-connection-part-5/[11]
Link: 3. https://tools.ietf.org/html/rfc5246
Link: 4. https://docs.microsoft.com/en-us/windows/desktop/secauthn/cipher-suites-in-schannel
Link: 5. https://www.websecurity.symantec.com/security-topics/what-is-ssl-tls-https
Link: 6. https://docs.apigee.com/api-platform/system-administration/keystores-and-truststores
Link: 7. https://wiki.openssl.org/index.php/Elliptic_Curve_Diffie_Hellman
Link: 9. https://www.ssl2buy.com/wiki/symmetric-vs-asymmetric-encryption-what-are-differences
Link: 10. https://www.geeksforgeeks.org/rsa-algorithm-cryptography/
Link: 11. https://www.acunetix.com/blog/articles/establishing-tls-ssl-connection-part-5/
https://medium.com/@kasunpdh/ssl-handshake-explained-4dabb87cdce
