Lab Exercise – SSL/TLS

Objective
To observe SSL/TLS (Secure Sockets Layer / Transport Layer Security) in action. SSL/TLS is used to secure
TCP connections, and it is widely used as part of the secure web: HTTPS is SSL over HTTP.

The principal motivation for HTTPS is authentication of the accessed website and protection of the pri-
vacy and integrity of the exchanged data. It protects against man-in-the-middle attacks. The bidirec-
tional encryption of communications between a client and server protects against eavesdropping and
tampering of the communication. In practice, this provides a reasonable assurance that one is communi-
cating without interference by attackers with the website that one intended to communicate with, as
opposed to an impostor. Historically, HTTPS connections were primarily used for payment transactions
on the World Wide Web, e-mail and for sensitive transactions in corporate information systems. Since
2018 HTTPS is more used on websites than the original non-secure HTTP; protecting page authenticity
on all types of websites, securing accounts and keeping user communications, identity and web brows-
ing private.

Step 1: Open a Trace

1. Open the Wireshark trace https://kevincurran.org/com320/labs/wireshark/trace-ssl.pcap

You should see the following trace.

Figure 1: Trace of “HTTPS” traffic

1
Step 2: Inspect the Trace
Now we are ready to look at the details of some “SSL” messages.

2. To begin, enter and apply a display filter of “ssl”. (see below)

This filter will help to simplify the display by showing only SSL and TLS messages. It will exclude other
TCP segments that are part of the trace, such as Acks and connection open/close.

Figure 2: Trace of “SSL” traffic showing the details of the SSL header

3. Select a TLS message somewhere in the middle of your trace for which the Info reads “Applica-
tion Data” & expand its Secure Sockets Layer block (by using the “+” expander or icon). For in-
stance, packet #12 (see below).

2
Application Data is a generic TLS message carrying contents for the application, such as the web page. It
is a good place for us to start looking at TLS messages.

The lower layer protocol blocks are TCP and IP because SSL runs on top of TCP/IP. The SSL layer contains
a “TLS Record Layer”. This is the foundational sublayer for TLS. All messages contain records. Expand this
block to see its details. Each record starts with a Content Type field. This tells us what is in the contents
of the record. Then comes a Version identifier. It will be a constant value for the SSL connection. It is fol-
lowed by a Length field giving the length of the record. Last comes the contents of the record. Applica-
tion Data records are sent after SSL has secured the connection, so the contents will show up as en-
crypted data. To see within this block, we could configure Wireshark with the decryption key. This is pos-
sible, but outside of our scope. Note that, unlike other protocols we will see such as DNS, there may be
multiple records in a single message. Each record will show up as its own block. Look at the Info column,
and you will see messages with more than one block.

The Content-Type for a record containing “Application Data” is 23. The version constant used in this
trace is 0x0301 which represents TLS 1.0. The Length covers only the payload of the Record Layer.

Step 3: The SSL Handshake

An important part of SSL is the initial handshake that establishes a secure connection. The handshake
proceeds in several phases. There are slight differences for different versions of TLS and depending on
the encryption scheme that is in use. The usual outline for a brand-new connection is:
a. Client (the browser) and Server (the web server) both send their Hellos
b. Server sends its certificate to Client to authenticate (and optionally asks for Client Certificate)
c. Client sends keying information and signals a switch to encrypted data.
d. Server signals a switch to encrypted data.
e. Both Client and Server send encrypted data.
f. An Alert is used to tell the other party that the connection is closing.

Note that there is also a mechanism to resume sessions for repeat connections between the same client
and server to skip most of steps b and c. However, we will not study session resumption.

Hello Messages
Next we will find and inspect the details of the Client Hello and Server Hello messages, including expand-
ing the Handshake protocol block within the TLS Record. For these initial messages, an encryption
scheme is not yet established so the contents of the record are visible to us. They contain details of the
secure connection setup in a Handshake protocol format.

3
 4. Select packet #4, which is a TLS Client Hello message

We can see several important fields here worth mentioning. First, the time (GMT seconds since midnight
Jan 1, 1970) and random bytes (size 28) are included. This will be used later in the protocol to generate
our symmetric encryption key. The client can send an optional session ID to quickly resume a previous
TLS connection and skip portions of the TLS handshake. Arguably the most important part of the Cli-
entHello message is the list of cipher suites, which dictate the key exchange algorithm, bulk encryption
algorithm (with key length), MAC, and a psuedo-random function. The list should be ordered by client
preference. The collection of these choices is a “cipher suite”, and the server is responsible for choosing
a secure one it supports or return an error if it doesn’t support any. The final field specified in the speci-
fication is for compression methods. However, secure clients will advertise that they do not support
compression (by passing “null” as the only algorithm) to avoid the CRIME attack. Finally, the ClientHello
can have a number of different extensions. A common one is server_name, which specifies the host-
name the connection is meant for, so webservers hosting multiple sites can present the correct certifi-
cate.

5. Select packet #6, which is a TLS Server Hello message

The session ID sent by the server is 32 bytes long. This identifier allows later resumption of the session
with an abbreviated handshake when both the client and server indicate the same value. In our case,
the client likely sent no session ID as there was nothing to resume (see below)

4
The Cipher method chosen by the Server is TLS_RSA_WITH_RC4_128_SHA (0x0005). The Client will list
the different cipher methods it supports, and the Server will pick one of these methods to use.

Certificate Messages

6. Next, find and inspect the details of the Certificate message including expanding the Handshake
protocol block within the TLS Record (see below for expansion of packet #7).

As with the Hellos, the contents of the Certificate message are visible because an encryption scheme is
not yet established. It should come after the Hello messages.

Note it is the server that sends a certificate to the client, since it is the browser that wants to verify the
identity of the server. It is also possible for the server to request certificates from the client, but this be-
havior is not normally used by web applications.

A Certificate message will contain one or more certificates, as needed for one party to verify the identity
of the other party from its roots of trust certificates. You can inspect those certificates in your browser.

5
Client Key Exchange and Change Cipher Messages

7. Find and inspect the details of the Client Key Exchange and Change Cipher messages i.e. packet
#9 (see below)

The key exchange message is sent to pass keying information so that both sides will have the same se-
cret session key. The change cipher message signal a switch to a new encryption scheme to the other
party. This means that it is the last unencrypted message sent by the party.

Note how the Client Key Exchange has a Content-Type of 22, indicating the Handshake protocol. This is
the same as for the Hello and Certificate messages, as they are part of the Handshake protocol.

The Change Cipher Spec message has a Content-Type of 20, indicating the Change Cipher Spec protocol
(see packet #10 – see below).

That is, this message is part of its own protocol and not the Handshake protocol.

Both sides send the Change Cipher Spec message immediately before they switch to sending encrypted
contents. The message is an indication to the other side. The contents of the Change Cipher Spec mes-
sage are simply the value 1 as a single byte. Actually, it is the value “1” encrypted under the current
scheme, which uses no encryption for the handshake so that we can see it.

6
Alert Message

8. Finally, find and inspect the details of an Alert message at the end of the trace (packet #42).

The Alert message is sent to signal a condition, such as notification that one party is closing the connec-
tion. You should find an Alert after the Application Data messages that make up the secure web fetch.

Note, the Content-Type value is 21 for Alert. This is a new protocol, different from the Handshake,
Change Cipher Spec and Application Data values that we have already seen.

The alert is encrypted; we cannot see its contents. Wireshark also describes the message as an “En-
crypted Alert”. Presumably is it a “close_notify” alert to signal that the connection is ending, but we can-
not be certain.