SSL Handshaking Overview

The goal of this post is to review what happens at the TCP/IP level when an SSL connection is initiated, paying particular attention to the parts of the handshake protocol that are synchronous, i.e., that result in the client or the server waiting for a response from the other before proceeding. Most of this post comes from the SSL 3.0 Specification listed on this web site and the TLS 1.0 Specification listed here.

Initiating a TCP Session

When a client such as a web browser first contacts a web site via SSL, the first thing that happens is a new TCP/IP session is initiated between the selected client port and the port handling SSL connections on the server, usually port 443:

This is a diagram of the standard 3-way handshake that initiates a TCP connection.

The TCP protocol provides reliable packet delivery by embedding a sequence number in every packet. Whenever an endpoint receives a TCP packet it responds with an acknowledgment (abbreviated as an “ACK”) indicating the highest sequence number it has successfully received. If the sender doesn’t receive and ACK for a packet it’s sent within a certain time period, it assumes the packet was lost, and re-sends it.

When an HTTPS request is sent to a server, the first thing that happens is that a new TCP/IP connection is established with the port the server uses for SSL connections, usually port 443.

The client issues a synchronization request (abbreviated as “SYN”), in which it indicates the client port number for the conversation, and with the initial sequence number for packets originating from the client.

The server responds by ACKing the client’s request, and with a SYN of its own, which contains its initial sequence number for packets originating from the server.

In the diagram, packets originating from the client are shown in blue, and packets originating from the server are in green. Dark-colored lines indicate synchronous conversations. E.g., the client sends its initial SYN and waits for the server to respond. The server responds, and the synchronous part of the conversation is completed. The client ACKs the server’s response, and then continues immediately with the next conversation, which is the client/server hello:

The Client and Server Hellos

In this diagram the client begins by sending the SSL Client Hello message, which contains, among other things, the highest version of SSL supported by the client, the list of encryption algorithms supported by the client, and a random number that will be used as a seed value for generating the SSL master secret encryption key.

This is a good time to note that SSL is based on both PKI encryption (public-key infrastructure) and on symmetric encryption. PKI encryption is based on a pair of keys, a public key and a private key. The properties of PKI encryption that make it so useful are these:

• Anything encrypted with the public key can only be decrypted with the private key.
• Anything encrypted with the private key can only be decrypted with the public key.

The server can therefore broadcast its public key to the world, and the client can use it to encrypt its messages without fear that anyone other than the holder of the private key can decrypt it. But PKI encryption is slow, so SSL uses it only to encrypt a seed value that is used to generate a symmetric key, which is used by the client and server to encrypt the rest of the conversation. Symmetric key encryption algorithms use a single key for both encryption and decryption. These algorithms are faster than PKI, but presuppose that the participants in the conversation have a secure way to exchange the encryption key.

In SSL, the conversation’s symmetric key is called the “master secret.” The key itself is not sent over the wire. Instead, three seed values are sent across the wire that the client and server can use to generate the actual symmetric key. The seed values include a random number generated on the client and sent to the server in the clear (unencrypted), a random number generated on the server and sent to the client in the clear, and another random number generated on the client and sent to the server encrypted via PKI.

Once the client sends the Client Hello it must wait for the server to respond with a set of messages that begin with a Server Hello message and end with a Server Hello Done. The messages sent by the server in between the Server Hello and the Server Hello Done depend on whether the server authenticates itself using digital certificates, and whether it requires clients to authenticate themselves with digitial certificates.

The diagram shows the most common case, in which the server authenticates itself to the client with a digital certificate, but does not require the client to authenticate itself.

In that scenario, the server selects the strongest encryption algorithm supported by both client and server, and returns its selection in the Server Hello, along with a random number generated on the server for use in creating the symmetric encryption key. It sends its digital certificate in a Server Certificate message, and then sends a Server Hello Done message.

As with the previous diagram, the synchronous part of the conversation uses dark colors. The ACKs are in lighter colors and are not synchronous. Which is to say, the client sends the Client Hello, and then waits for the stream of messages ending with the Server Hello Done. Neither side waits for the ACKs.

The client is now ready to send the information the server will need to generate the symmetric encryption key, and to instruct the server to switch to the chosen symmetric encryption algorithm:

The Client and Server Key Exchange, Change Cipher Specs and Finished Messages

In this diagram the client generates the information necessary for the client and server to generate the “master secret,” which is the symmetric encryption key. The exact information sent differs based on the encryption algorithm used. The client sends this in an SSL Client Key Exchange message.

The client then sends a Change Cipher Specs message, which is just a flag message that contains no data payload, and then a Finished message, which is the first message encrypted using the symmetric key. The content of the message is the entire handshake conversation up to the Change Cipher Specs message, which the recipient will decode to verify that encryption is working properly.

The server must wait to receive the client key information before proceeding with its part of the conversation, but the client doesn’t have to wait for the server to do so before it starts to send encrypted content under the session, so the synchronous part of the SSL setup has effectively concluded.

The server does reciprocate with its own Change Cipher Specs and Finished message however, which again contains an encrypted copy of the entire handshaking exchange between itself and the client. The client is also required to decrypt the Finished message payload and verify that encryption is working properly.

At this point the SSL connection, and the client and server may exchange encrypted content.

Viewing the Packets in Wireshark

All this becomes more concrete when the packets are viewed in a packet sniffer such as Wireshark. Wireshark is very easy to use. Just download, install and run the application, and select Capture\Interfaces... in order to instruct Wireshark to start capturing packets on one of your network devices. If several devices are listed and you're not certain which to capture, just leave the dialog open for moment while you browse the Internet. The number in the "Packets" column in the dialog will increase on the network device being used by the browser.

Next, find a web site that uses HTTPS, and load a web page from that site in your browser. You'll want to filter out all the network traffic except packets that are going to or coming from that site. You should be able to figure out the IP address of the site you're connecting to by viewing the packet stream in Wireshark as you refresh the browser. In my case I'm using a site with IP address 72.21.210.250. Once you've figured that out, add a filter to Wireshark Filter text box of this form: ip.dst == 72.21.210.250 or ip.src == 72.21.210.250.

To get a clear picture of an entire SSL session, its best to wait a few minutes until the server you've connected to terminates your TCP connection. You'll see that happen in Wireshark when the server sends a TCP "FIN" message to your machine, which Wireshark highlights in dark gray by default. Then select Capture\Restart in Wireshark, and refresh the HTTPS page in your browser. You'll see something like this:

Initiating the TCP Session

The first message packet is the client's TCP SYN, requesting a new session containing the client port, 51805, and the starting packet sequence number, zero. The server ACKs the client's SYN and responds with a SYN of its own in the next message:

Wireshark helpfully colors the two SYN packets in dark gray to highlight the fact that they represent the beginning of a new TCP session, and includes a "SEQ/ACK" analysis feature in its Packet Details pane that shows that the ACK in this packet is acknowledging receipt of the packet sent in frame 5 above.

At this point we have a valid TCP session. The client ACKs the receipt of the server SYN, and then immediately proceeds to the Client Hello:

Client and Server Hellos

Wireshark notes that this is a TLS 1.0 (Transport Layer Security) message by identifying the protocol as TLSv1. TLS 1.0 is basically a newer variant of SSL 3.0. The aspects of the handshaking protocols that I'm reviewing in this blog post used by the two protocols are the same, with one exception that I will note below.

The server responds with two packets. The first is this:

Wireshark flags this as a "TCP segment of a reassembled PDU" (Protocol Data Unit). This is just a way of saying that a single higher-level protocol's "data unit" (a TLSv1 record in this case) has been broken up into two TCP packets for transmission.

Expanding the Transmission Control Protocol node in the Packet Details pane, we can also see that this packet contains an ACK for the packet the client last sent.

Moving on to frame 10 we can see that the server has packaged three SSL messages into a single data unit: a Server Hello, the Certificate, and the Server Hello Done:

In the Packet Details pane, Wireshark helpfully tells us that this single TLSv1 data unit has been reassembled from two TCP packets, which are shown in frames 9 and 10. Looking at the Secure Socket Layer info in the packet, we see the three messages. If we then expand the Server Hello details, we can see that the server selected the RSA PKI algorithm and the RC4 symmetric encryption algorithm using a 128-bit key, and the MD5 algorithm for hashing:

Client and Server Key Exchanges

In frame 11 the client ACKs the server hello messages, and in frame 12 it immediately proceeds to the Client Key Exchange, Change Cipher Specs, and Finished message (which Wireshark calls an "Encrypted Handshake Method"), all of which are contained in a single TCP packet:

Frame 13 is a server ACK, and in frame 14 we get the server's Change Cipher Specs and Finished messages:

And in Frame 15 we see the start of the actual SSL-encrypted content of the web page.

Another Synchronous Handshake in TLS 1.0

One interesting thing to note about these Wireshark results is that, even though the client is supposed to be able to begin sending data as soon as it completes its client Finished message, in the results above it appears to wait until the server completes its server Finished message.

This appears to be the only difference that we have encountered in this post between the SSL 3.0 spec and the TLS 1.0 spec. The SSL 3.0 spec contains the phrase "No acknowledgment of the finished message is required" in its description of the client Finished message. That phrase has been removed from the TLS 1.0 spec, which is otherwise in many places a word-for-word copy of the SSL 3.0 spec. Also the flow diagram used by TLS 1.0 has been changed to make the client and server key exchange conversations synchronous.

Therefore it would appear that for TLS 1.0 the key exchange diagram should look like this:

to reflect the fact that the key exchange messages have been made synchronous in the newer protocol.