How does SSL/TLS work - part two

As part one explained, SSL/TLS is intended to provide secure network connections between a client (e.g. a web browser), and a server (e.g. a web server) by encrypting all data that is passed between them.

To achieve this, public key encryption is used to verify the parties in the encrypted session, and to provide a way for client and server to agree on a shared symmetric encryption key. This post explains the process in more detail.

The handshake is the most critical part of SSL/TLS, as this is where the important parameters for the connection are established. The various steps in the handshake are described below.

Step 1 - client hello

After setting up a TCP/IP connection, the client sends a ClientHello message to the server. This states the maximum TLS version the client is willing to support, a random number, the list of cipher suites supported in order of preference, and the compression algorithms. Cipher suites are identifiers for a group of cryptographic algorithms that are used together. For example, TLS_RSA_WITH_AES_128_CBC_SHA means that the server's RSA public key is to be used, and the encryption algorithm is 128 bit AES. The MAC algorithm (see here) is HMAC/SHA-1.

The ClientHello is sent in cleartext, so anyone able to sniff the network packets can read it.

Step 2 - server hello

The server replies to the ClientHello with a ServerHello message. It tells the client the TLS version to use, together with the cipher suite and compression algorithm it has chosen. The ServerHello also provides a server-generated random number and a session identifier. The ServerHello is also sent in cleartext.

Step 3 - server certificate

Immediately after sending its ServerHello, the server sends its certificate, containing its public key, to the client. Typically, the client has a cache of certificates or CA root certificates by which it can verify that the server's certificate is genuine (and registered to the server's IP address). If the server's certificate is unknown, the client may give the option of accepting the certificate anyway (which is potentially dangerous), or may sever the connection. This message is sent in cleartext.

Step 4 - server hello done

After sending its certificate, the server now sends an optional ServerKeyExchange message which contains any additional required values for the key exchange.

If the server is configured to require the client to identify itself with a client certificate, the server asks for it at this point in the handshake via the optional CertificateRequest message.

Finally, the server sends the client a ServerHelloDone message, still in cleartext.

Step 5 - client response

If the server requested a certificate from the client, the client sends its certificate, followed by the ClientKeyExchange message.

For the ClientKeyExchange message, the client generates what is called the premaster secret, consisting of 48 bytes. This secret is sent to the server as part of this message, but is encrypted with the server's public key (obtained from the server's certificate) so that only the server can decrypt it with its private key (as messages are still being sent as plain text).

Once the client and server share the premaster secret, they each use it in combination with both of the random values that have been exchanged earlier to produce the master secret and subsequently the session keys - the symmetric keys used to encrypt and decrypt data in the subsequent TLS session.

The ChangeCipherSpec message is sent after the ClientKeyExchange message. This message indicates to the server that all subsequent messages will be encrypted using the newly created session keys. It is followed by the Finished message, the first to be encrypted. The Finished message is a hash of the entire handshake so far that enables the server to verify that this was the client that has been communicating with the server throughout the handshake.

Step 6 - server finished

The server replies to the Finished message from the client with a ChangeCipherSpec message of its own, followed by an encrypted Finished message, which again is a hash of the handshake to this point. This enables the client to verify that this is the same server that has been communicating with it during the handshake.

By this point, all messages are encrypted and so a secure communication channel across the network between client and server has been established.

The next post in this series will look at SSL/TLS records and alerts, which are important features of this protocol.

Posted by John Faulds in