Network Security

SSL/TLS Lab Exercises

Objectives
Observe the SSL/TLS (Secure Sockets Layer / Transport Layer Security) protocol in operation. TLS is used to
secure TCP connections, and is widely used as part of the secure web: HTTPS is HTTP over SSL.
The main motivation of HTTPS is the authentication of the accessed website and the protection of the privacy
and integrity of the exchanged data. It protects against MIM (man-in-the-middle) attacks. Bidirectional
encryption of communications between a client and a server protects against eavesdropping and
communication deception. In practice, this provides reasonable assurance that you are communicating,
without interference from attackers, with the website you are trying to communicate with, and not with an
imposter. Historically, HTTPS connections were first used for web payment transactions, email, and for
sensitive transactions on enterprise information systems. As of 2018, HTTPS is used on more websites than
the non-secure HTTP protocol; protecting the authenticity of pages on all types of websites, securing accounts
and keeping users' communications, identity and browsing private.

Exercise 1: Inspecting and analyzing a sample trace

Open the Wireshark trace contained in the file "trace-ssl.pcap".
We should see a content similar to that of Figure 1.

Figure 1: "HTTPS" traffic trace.

1
 Analyze the TLS trace
Now, we are ready to look at the details of some TLS messages.
To begin with, we are going to enter and apply a display filter "tls" (or "ssl").
This filter helps 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 opens and closes.

Figure 2TLS" traffic trace showing the details of the TLS header.

Next, let's select a TLS message from the trace in which the "Application Data" information appears, and
expand the Transport Layer Security block (using "+" or the icon). For example, we can see packet #12 (see
Figure 3).

2
 Figure 3Example of a trace Application Data package.

"Application Data" is a generic TLS message that carries application data, such as the web page, for example.
We can start here to look at TLS messages.
The lower level protocol blocks are TCP and IP, as TLS runs over TCP/IP. The TLS level contains the "TLS Registry
Level". This is the basic sub-level of TLS. All messages contain logs. We can expand this level to see its details.
Each record starts with a Content-Type field, which tells us what the record contains. Next comes a Version
Identifier, which will remain constant throughout the TLS connection. It is followed by a Lenght field, which
tells us the length of the record. At the end is the content of the record. Application Data records are sent
once the TLS connection is secure and therefore the content appears as encrypted data. In order to see the
content of these blocks, we can configure Wireshark with the decryption key. Note that, unlike other protocols
that we can look at such as DNS, multiple records can be presented in a single message. Each record will be
displayed in its own block. We can observe the Info column, where messages with more than one block will
appear.
The value of the Content-Type field for an Application Data record is 23. The constant version shown in this
example trace is 0x0301, which represents TLS 1.0. The Length field only covers record-level data.
Analysis of the TLS (Handshake) greeting
A very important part of TLS is the initial handshake that establishes the secure connection. The handshake
protocol takes place in several phases. There are significant differences in the various versions of TLS and
depending on the encryption scheme used. The usual progression of a new connection is:
1. Client (the browser) and Server (the web server) send their "Hello" messages.
2. The server sends its certificate to the client for authentication (and optionally requests the Client's
certificate).
3. The Client sends the key information and signals a change to the data encryption.
4. The Server signals the change to data encryption.

3
 5. Both Client and Server send encrypted data over the connection.
6. An "Alert" is used to notify the other party of the connection closure.

In addition, there is a mechanism to resume sessions for repeated connections between the same client and
server, to avoid most of steps 2 and 3.
Hello messages
Next, we will look for and inspect the details of the client and server Hello messages, including the expansion
of the Handshake Protocol block in the TLS record. In these initial messages, no encryption scheme has yet
been established and therefore the contents of the logs are visible. They contain details of the secure
connection configuration in the Handshake Protocol format.
To do this, we will select packet #4, which is a Client Hello TLS message.

Figure 4Client Hello TLS message.

We can see several important fields to mention. First, the time (in seconds GMT from 00:00h, Jan 1, 1970)
and a block of random bytes (28 bytes) 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 parts of the TLS handshake protocol. Possibly the most important part of the Client Hello
message is the list of cryptographic suites, which determines the key exchange algorithm, the data encryption
algorithm (with key length), the MAC, and a pseudo-random function. The list will be sorted according to the
customer's preferences. The collection of these options is a "cryptographic suite" and the server is responsible
for either choosing a secure one to implement or returning an error if it does not implement any of them. The
final field indicated in the specification is for the compression method. However, secure clients can warn that
they do not support compression (indicating "null" as the only algorithm) to avoid CRIME attacks. Finally,
Client Hello can include several extensions. A very common extension is Server Name, which specifies the
hostname to which the connection is supposed to be directed, so that web servers supporting multiple
websites can present the correct certificate.

Next, we select packet #6, which is a TLS Server Hello message.

The session ID sent by the server is 32 bytes. This identifier allows subsequent resumption of the session with
an abbreviated handshake process, when both the client and the server indicate the same value. In our case,
the client probably did not send any session ID, and therefore, there is nothing to resume (see the Figure 5).

4
 Figure 5Server Hello TLS message.

The encryption method chosen by the Server is TLS_RSA_WITH_RC4_128_SHA (0x0005). The Client would
have listed all the methods it implements and the Server has chosen one of those methods for use.
Certificate Message
Next, we look for and inspect the details of the Certificate message, including the expansion of the
Handshake Protocol block of the TLS registry (see Figure 6). Figure 6 with the expansion of packet #7).

Figure 6Certificate message.

5
As with Hello messages, the content of Certificate messages is visible because no encryption scheme has yet
been established. It will be done after the Hello messages.

Note that it is the server that sends a certificate to the client, since it is the browser that wants to verify the
server's identity. In addition, it is possible for the server to request a certificate from the client, although this
behavior is less common in web applications (it is usually used for user authentication).

The Certificate message contains one or more certificates (a chain of certificates), as needed for a participant
to verify the identity of the other party from its root of trust certificates. We can inspect these certificates in
our browser.
Client Key Exchange and Change Cipher messages
We look for and inspect the details of the Client Key Exchange and Change Cipher messages, for example
packet #9 (see Figure 8). Figure 7).

Figure 7Client Key Exchange and Change Cipher Spec messages.

The key exchange message is sent to pass the key information so that both parties can obtain the same secret
session key. The Change Cipher message signals to the other party the change to the new encryption scheme.

Note that the Client Key Exchange message uses the value 22 in the Content-Type field, indicating the
Handshake Protocol. This is the same value as in the Hello and Certificate messages, as they are all part of the
Handshake Protocol.
The Change Cipher Spec message uses the value 20 in the Content-Type field, indicating the Change Cipher
Spec protocol (see packet #10).
That is, this message is part of its own protocol and is not part of the Handshake Protocol.

Both parties send the Change Cipher Spec message immediately before switching to sending encrypted
content. The message is an indication to the other party. The content of the Change Cipher Spec messages is
only the value 1, in a single byte. Actually, it is the value 1 encrypted under the current encryption scheme,
which does not use encryption in the handshake, so we can see it.
6
 Alert Message
We search and inspect the details of an Alert message at the end of the trace (packet #42).

The Alert message is sent to signal a situation, such as notification that one of the parties is closing the
connection. We should find an alert after the Application Data messages that create the secure web search.

Figure 8Warning message.

Note that the value of the Content-Type field is 21 in Alert messages (see Figure 8). Figure 8). This is a new
protocol, different from those used in Handshake, Change Cipher Spec or Application Data, which we have
already seen.
The alert is encrypted; we cannot see its contents. Wireshark also describes the message as "Encrypted Alert".
This is probably a "close_notify" alert, to indicate that the connection is being terminated, but we cannot be
sure.

Exercise 2: Capture and analysis of traffic generated on a secure connection.

In this exercise we will proceed to make a secure connection to an external web server, using a browser, and
capture the traffic generated using wireshark. Subsequently, we will proceed to perform an analysis and
identification of the messages of such capture, following a procedure similar to that of the previous exercise.
We will write an explanatory report.
Process:
1. Preparation and implementation of Wireshark capture on the network interface used.
2. Browser connection to the web site to be used (e.g. www.google.com, www.unex.es, ...)
3. Traffic analysis:
a. Identification and filtering of the traffic we are interested in.
b. Analysis of Hello messages.
c. Analysis of server messages (Certificate, ...).
d. Analysis of customer messages (key information, ...).
e. Messages of change to data encryption.
f. Client and server messages encrypted with the new parameters.
g. Alert messages.
h. Other messages.
4. Comments on the process analyzed (issues to be highlighted, differences, ...)

Exercise 3: Obtain the TLS message table in wireshark.

7
In this exercise we will proceed to use wireshark to display a graph with the table of messages exchanged
between the client and the server on a TLS connection. We will write an explanatory memory.
Process:
1. Connect via a browser to the web site to be used (e.g. www.google.com, www.unex.es, ...) and
capture the messages with wireshark, or open with wireshark the example trace file from the previous
exercises.
2. If necessary, filter the captured messages, to display only those corresponding to the traffic between
our machine and the web server.
3. Select the first message and access the "Statistics/Flow chart" option. Activate the "Use display filter"
option.
4. Capture and comment on the graph obtained.

Exercise 4: Decryption of TLS traffic in wireshark.

In this exercise we will proceed to configure wireshark to use the log files and the pre-master secret to decrypt
the data of a TLS connection. Subsequently, we will proceed to repeat the previous exercise, that is, to make
a secure connection to an external web server, using a browser, and capture the traffic generated using
wireshark. In this case, we will be able to observe how wireshark decrypts and displays the content of all the
packets encrypted in the TLS connection (Application Data, ...). We will write an explanatory report.
Process:
5. Configure the system and Wireshark to decrypt TLS connections. To do this, we can follow the guides:
https://unit42.paloaltonetworks.com/wireshark-tutorial-decrypting-https-traffic/, or
https://wiki.wireshark.org/TLS.
6. Connection via a browser to the web site to be used (e.g. www.google.com, www.unex.es, ...).
7. Identification and filtering of the traffic we are interested in.
8. Client and server messages decrypted by wireshark.
9. Comments on the process analyzed (issues to be highlighted, differences, ...)

Exercise 5: Analysis of a TLS connection with client authentication.

In this exercise we will proceed to make a connection to an external web server that requests authentication
by the client using a public key certificate (we can use the example suggested in the FNMT Public Key
Certificates task), we will use our public key certificate to authenticate, and we will access the web. We must
capture the generated traffic using wireshark.
Subsequently, we will analyze this traffic and look at the messages in which the server requests authentication
from the client and the client sends its certificate, commenting on these messages.

Exercise 6: Capturing a Server Certificate with wireshark and other tools

In this exercise we will proceed to investigate the possibility of capturing the public key certificate of a server
that we access with TLS, save it in a file and examine it, using wireshark and other tools that allow us to access
the downloaded files and the certificates of the server to which it has connected. To do this, we should
investigate the use of auxiliary tools such as NetworkMiner and/or ssldump.
NetworkMiner is an open source network forensic analysis tool, available for various platforms
(https://www.netresec.com/?page=NetworkMiner), which allows us to perform this operation very easily.
Ssldump is a command line tool, available for Linux environments, that allows us to access and analyze the
content of files with TLS/SSL traffic captures.