The SSL (Secure Sockets Layer) handshake is the process that establishes an encrypted connection between a client and a server over the internet. It allows the client and server to authenticate each other and negotiate encryption algorithms and cryptographic keys before any data is transmitted.
How Does SSL Handshake Work?
The SSL handshake involves the following steps:
1. Client Hello
The client initiates the SSL handshake by sending a “ClientHello” message to the server. This message contains the client’s SSL version number, list of supported ciphers, a randomly generated session ID, and other information the server needs to communicate with the client using SSL.
2. Server Hello
The server responds by sending a “ServerHello” message, which contains the SSL version the server will use, the cipher the server selected from the client’s list, the session ID, and its cryptographic certificate.
3. Certificate Exchange
The server sends its digital certificate to the client. The certificate contains the server’s public key and identity information signed by a Certificate Authority (CA), which the client will use to authenticate the server.
The client verifies the server’s certificate against its list of trusted CAs. If valid, the client generates a premaster secret, encrypts it with the server’s public key, and sends it to the server.
4. Server Confirmation
The server decrypts the premaster key using its private key and confirms it matches the client’s version by sending a confirmation message.
5. Session Keys Generation
The client and server both generate session keys from the premaster secret and the random numbers exchanged in the hello messages earlier. These session keys will be used to encrypt all transmitted data.
6. Finish Handshake
The client sends a “Finished” message encrypted with the session key indicating the handshake is complete.
The server sends its own “Finished” message encrypted with the session key.
The SSL handshake is now complete. The client and server can begin transmitting encrypted data over the secure connection they have established.
Why is SSL Handshake Important?
The SSL handshake performs crucial functions that make SSL encryption secure:
- Authentication: The server certificate verifies the server’s identity, so the client knows it is not communicating with an imposter.
- Negotiating Encryption: The client and server agree on the strongest encryption algorithm they both support to secure the data.
- Exchanging Keys: The public and private keys are exchanged to enable asymmetric encryption of the premaster secret from which the symmetric session keys are derived.
- Integrity Checking: The finished messages check the handshake completed without tampering by an attacker.
Without a proper SSL handshake, the data exchange between client and server could be vulnerable to eavesdropping and manipulation by malicious parties. The handshake ensures only the legitimate client and server at each end can decrypt the transmitted information.
SSL Handshake Process Explained Step-by-Step
Let’s look at what exactly happens during each stage of the SSL handshake process:
1. Client Hello
The client initiates the SSL handshake to establish a secure connection with the server. The client sends a “ClientHello” message which includes the following information:
- Client SSL Version: The highest SSL/TLS version supported by the client.
- Supported Ciphers: A list of symmetric encryption algorithms supported by the client in order of preference, e.g. AES256, AES128, 3DES, RC4.
- Compression Methods: The compression algorithms supported by the client.
- Random Number: A client-generated random number used to generate the symmetric keys.
- Session ID: The ID of an existing SSL session if the client wants to reuse parameters from a previous connection.
- Extensions: Optional extensions supported by the client such as Server Name Indication (SNI).
2. Server Hello
The server receives the ClientHello message and responds with a ServerHello message containing:
- SSL Version: The SSL version picked by the server from options sent by client.
- Selected Cipher: The single symmetric encryption algorithm chosen by server from client’s list.
- Compression Method: The compression method selected by server from client’s options.
- Random Number: A server-generated random number to be used in key generation.
- Session ID: If the server accepts client’s session ID, it is echoed here. Otherwise, a new ID is generated.
- Extensions: Any extensions supported by server.
At this stage, the server has chosen the parameters for the SSL session.
3. Server Certificate Exchange
The server sends its digital certificate to the client so the client can authenticate the server.
The certificate contains:
- Server Public Key: Used by client to encrypt data to the server.
- Signature Algorithm: Algorithm used by the CA to sign the certificate.
- Validity Period: Start and end date between which the certificate is valid.
- Issuer Name: The CA that issued and signed the certificate.
- Subject Name: The server’s legal name and ownership details.
- Public Key Fingerprint: Hash of the public key to identify it.
The client will verify:
- The certificate is issued by a trusted CA.
- The certificate is valid and unexpired.
- The domain name matches the server’s domain.
If the checks pass, the server has been successfully authenticated.
4. Client Certificate Exchange
If the server requests client authentication, the client sends its certificate following the same process the server did.
The client also generates a premaster secret, encrypts it with the server’s public key from its certificate, and sends it to the server.
5. Server Confirmation
The server receives the premaster secret. It decrypts it using its private key to obtain the premaster secret.
The server then generates a hash of all the handshake messages exchanged so far. It encrypts this hash digest with the premaster secret and sends it to the client.
This confirms the server was able to correctly decrypt the premaster secret using its private key.
6. Session Keys Generation
The premaster secret is used by both client and server to generate symmetric session keys that will secure the data transmission.
The client and server each generate two keys:
- Client Write Key: Encrypts data sent by client.
- Server Write Key: Encrypts data sent by server.
- Client Write MAC Key: Generates a MAC for data sent by client.
- Server Write MAC Key: Generates a MAC for data sent by server.
These keys are generated using the premaster secret, client and server random numbers, and handshake data through a Key Derivation Function (KDF).
7. Client Finish
The client sends a Finish message that contains a hash and MAC of the handshake so far, encrypted with the client write key and client write MAC key.
This verifies the client was able to derive the symmetric keys successfully.
8. Server Finish
The server sends its own Finish message containing the hash and MAC of the handshake, encrypted with the server’s write key and MAC key.
This verifies the server correctly calculated the session keys and is ready to start transmitting encrypted application data.
At this point, the SSL handshake is complete. The client and server can now use the established keys and encryption algorithm to secure the application layer data they transmit.
SSL Handshake Diagram
Here is a diagram summarizing the full SSL handshake process:
The SSL handshake establishes an encrypted tunnel between the client and server through which all application data flows securely.
Variations in the SSL Handshake Process
While the SSL handshake generally follows the steps outlined above, there are some variations depending on the protocols and configurations used:
- For SSL 2.0 and 3.0, the order of Certificate Exchange and ServerHello is reversed. The client sends its certificate first before the server does.
- Client authentication via certificates is optional and the Client Certificate Exchange is omitted if not needed.
- In TLS 1.3, some steps like compression negotiation and client certificate exchange are removed for simplicity and security.
- Resumption handshakes that reuse session IDs or session tickets can skip some steps to establish the connection faster.
- Front-end load balancers may decrypt and re-encrypt the handshake before passing it to backend servers.
Why Multiple Rounds of Encryption?
Astute readers may wonder why the handshake uses multiple rounds of encryption: why not just encrypt everything with the session key from the beginning?
There are two reasons:
- The server needs to prove it owns the private key before using it to generate the shared secret. So, it has to encrypt something with it first.
- The session keys are derived from the shared premaster secret. The client and server need to securely exchange the premaster secret before being able to calculate the session keys.
So asymmetric encryption is initially used to protect the premaster secret exchange.
Conclusion
The SSL handshake is a critical process that establishes secure encrypted communication between a client and server. By exchanging keys and certificates, authenticating identities, negotiating encryption algorithms, and verifying the integrity of the handshake, the client and server are able to communicate privately over an encrypted tunnel. The multi-step handshake ensures no third party can eavesdrop or tamper with the messages exchanged between client and server. While there are some variations, the core purpose of the SSL handshake remains to develop trust and spawn cryptographic keys to initiate a secure session.
FAQs on SSL Handshake
What happens if SSL handshake fails?
If the SSL handshake fails, the client will not be able to establish an encrypted session with the server. This could happen due to misconfigured certificates, incompatible cipher suites, or interference from an attacker. The connection will be aborted, and no data will be exchanged.
Does the SSL handshake happen again after the initial connection?
Typically, no, the SSL handshake only occurs at the start of a new SSL session. The negotiated keys are reused in subsequent connections until the session expires or is reset.
What are the main SSL handshake protocols?
The primary protocols used for SSL handshakes are SSL 3.0, TLS 1.0, 1.1, 1.2 and 1.3. TLS 1.2 is currently the most widely used. SSL 2.0 is obsolete and insecure.
What is abbreviated handshake in SSL?
Abbreviated SSL handshakes optimize performance by resuming previous sessions and avoiding recalculating keys. The client sends the Session ID of a previous connection in its hello message.
Can you decrypt SSL traffic?
It is possible to decrypt SSL traffic if you have the server’s private key. Otherwise, SSL-encrypted data cannot be easily decrypted without breaking the encryption.
What is SSL renegotiation?
SSL renegotiation allows the client and server to re-perform the SSL handshake on an existing connection to establish new keys and parameters.
What port number is used for SSL?
SSL commonly uses port 443 for HTTP over SSL (HTTPS) and port 465 for SMTP email connections over SSL.
