TCP 3‐way handshake VS ssl tls handshakes - unix1998/technical_notes GitHub Wiki

SSL/TLS does have a handshake process, but it is not the same as the TCP three-way handshake. here is break down both handshakes:

TCP Three-Way Handshake

The TCP three-way handshake is a method used to establish a reliable connection between a client and a server. It involves three steps:

  1. SYN: The client sends a SYN (synchronize) packet to the server to initiate a connection.
  2. SYN-ACK: The server responds with a SYN-ACK (synchronize-acknowledge) packet, acknowledging the client's request and indicating its readiness to establish a connection.
  3. ACK: The client sends an ACK (acknowledge) packet back to the server, confirming the connection is established.

This process ensures both parties are synchronized and ready to communicate.

SSL/TLS Handshake

The SSL/TLS handshake is more complex and involves multiple steps to establish a secure encrypted connection. Here’s a simplified version of the typical steps involved in an SSL/TLS handshake:

  1. ClientHello: The client sends a ClientHello message to the server, which includes information like the SSL/TLS version, cipher suites supported, and a randomly generated number.
  2. ServerHello: The server responds with a ServerHello message, which includes the SSL/TLS version and cipher suite selected, and another randomly generated number.
  3. Server Certificate: The server sends its digital certificate to the client for authentication. This certificate contains the server’s public key.
  4. ServerKeyExchange (optional): If the server requires it (e.g., in the case of Diffie-Hellman key exchange), it sends a ServerKeyExchange message.
  5. CertificateRequest (optional): The server can request a certificate from the client to authenticate the client.
  6. ServerHelloDone: The server signals it is done with its initial negotiation messages with a ServerHelloDone message.
  7. Client Certificate (optional): If the server requested a certificate, the client sends its certificate for mutual authentication.
  8. ClientKeyExchange: The client sends a ClientKeyExchange message, which may include a pre-master secret, depending on the chosen cipher suite.
  9. CertificateVerify (optional): If client authentication is performed, the client sends a CertificateVerify message to prove ownership of the private key corresponding to the client certificate.
  10. ChangeCipherSpec: The client sends a ChangeCipherSpec message to inform the server that all subsequent data will be encrypted using the negotiated keys and algorithms.
  11. Finished: The client sends a Finished message, which is encrypted and contains a hash of the entire handshake up to this point.
  12. ChangeCipherSpec: The server responds with its own ChangeCipherSpec message.
  13. Finished: The server sends a Finished message, also encrypted and containing a hash of the handshake.

Once these steps are completed, the SSL/TLS handshake is finished, and a secure encrypted communication channel is established between the client and the server.

Key Differences

  • Purpose: The TCP handshake establishes a basic connection; the SSL/TLS handshake establishes a secure connection with encryption and authentication.
  • Complexity: The TCP handshake is simpler, involving only three steps, while the SSL/TLS handshake involves multiple steps with optional messages depending on the security requirements.
  • Authentication and Encryption: The TCP handshake does not involve authentication or encryption, while the SSL/TLS handshake involves exchanging certificates, verifying identities, and negotiating encryption algorithms.

In summary, while both handshakes aim to establish connections, the SSL/TLS handshake is more elaborate, providing security features that the TCP handshake does not.