# SSL Handshake Explained  URL:: https://medium.com/@kasunpdh/ssl-handshake-explained-4dabb87cdce Author:: Kasun Dharmadasa ## Highlights > 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. ([View Highlight](https://read.readwise.io/read/01febfpsb4ekchx85w47m2t5jd)) > 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. ([View Highlight](https://read.readwise.io/read/01febfq617tbvsheym9j2gt8np)) > **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. ([View Highlight](https://read.readwise.io/read/01febfqcmd461vpzdz3gfyt29h)) > **3. Server Key Exchange Message** ([View Highlight](https://read.readwise.io/read/01febxg8ye6ztqrp3fwpjttf7k)) > 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. ([View Highlight](https://read.readwise.io/read/01febxgf440qhsnw8dxzkhbvk3)) > **4. Certificate Request** ([View Highlight](https://read.readwise.io/read/01febxggvs8hde0dvphhnk65db)) > 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. ([View Highlight](https://read.readwise.io/read/01febxgmv1a9j5whcaeq5xqzea)) > 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) ([View Highlight](https://read.readwise.io/read/01febxgtth9g2mnzmqs0n5798c)) > 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. ([View Highlight](https://read.readwise.io/read/01febxgy8k7zb2mw7kbghjf11x)) > **5. Client Certificate** ([View Highlight](https://read.readwise.io/read/01febxh005ss0d07188p6yf1s7)) > 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. ([View Highlight](https://read.readwise.io/read/01febxh1z9122qzbmpxzjh101t)) > **6. Client Key Exchange Message** ([View Highlight](https://read.readwise.io/read/01febxh2jqvyqzh7bxa8bbwbcb)) > **7. Finished** ([View Highlight](https://read.readwise.io/read/01febxhbqceg5djxm20kn5tp64)) > 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. ([View Highlight](https://read.readwise.io/read/01febxhn3q3jpatha7m7g7g9rr)) --- Title: SSL Handshake Explained Author: Kasun Dharmadasa Tags: readwise, articles date: 2024-01-30 --- # SSL Handshake Explained  URL:: https://medium.com/@kasunpdh/ssl-handshake-explained-4dabb87cdce Author:: Kasun Dharmadasa ## AI-Generated Summary If you have ever browsed an HTTPS URL through a browser, you have experienced the SSL handshake. Even though might not notice it, the… ## Highlights > 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. ([View Highlight](https://read.readwise.io/read/01febfpsb4ekchx85w47m2t5jd)) > 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. ([View Highlight](https://read.readwise.io/read/01febfq617tbvsheym9j2gt8np)) > **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. ([View Highlight](https://read.readwise.io/read/01febfqcmd461vpzdz3gfyt29h)) > **3. Server Key Exchange Message** ([View Highlight](https://read.readwise.io/read/01febxg8ye6ztqrp3fwpjttf7k)) > 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. ([View Highlight](https://read.readwise.io/read/01febxgf440qhsnw8dxzkhbvk3)) > **4. Certificate Request** ([View Highlight](https://read.readwise.io/read/01febxggvs8hde0dvphhnk65db)) > 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. ([View Highlight](https://read.readwise.io/read/01febxgmv1a9j5whcaeq5xqzea)) > 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) ([View Highlight](https://read.readwise.io/read/01febxgtth9g2mnzmqs0n5798c)) > 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. ([View Highlight](https://read.readwise.io/read/01febxgy8k7zb2mw7kbghjf11x)) > **5. Client Certificate** ([View Highlight](https://read.readwise.io/read/01febxh005ss0d07188p6yf1s7)) > 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. ([View Highlight](https://read.readwise.io/read/01febxh1z9122qzbmpxzjh101t)) > **6. Client Key Exchange Message** ([View Highlight](https://read.readwise.io/read/01febxh2jqvyqzh7bxa8bbwbcb)) > **7. Finished** ([View Highlight](https://read.readwise.io/read/01febxhbqceg5djxm20kn5tp64)) > 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. ([View Highlight](https://read.readwise.io/read/01febxhn3q3jpatha7m7g7g9rr))