Wireshark course
Lab exercises
Network security protocols
T HE EXERCISES ARE BASED ON THE COURSE OF J IM K UROSE AND K EITH ROSS .
gaia.cs.umass.edu/kurose/_ross/wireshark.php
Dr. Stefan Hommes
Atlantis Cybersecurity Services, May 2023
Contents
1 TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1 Important commands 5
1.2 Questions: Capturing packets in an TLS session 5
1.3 Questions: The TLS Handshake: Client Hello message 6
1.4 Questions: The TLS Handshake: Server Hello message 7
1.5 Questions: The TLS Handshake: wrapping up the handshake 10
1.6 Questions: Application data 11
1. TLS
1.1 Important commands
Display filter: tls
1.2 Questions: Capturing packets in an TLS session
A user is making a HTTP request to
https://cics.umass.edu
and downloads the HTTP page.
Alternative: Import tls-wireshark-trace1.pcap in Wireshark and answer the following questions.
Let’s first set Wireshark’s display so that only the packets to and from www.cics.umass.edu,
whose IP address is 128.119.240.84, are displayed. To do this, enter
ip.addr == 128.119.240.84
in Wireshark’s display filter window.
1.2.1 What is the packet number in your trace that contains the initial TCP SYN message?
6 Chapter 1. TLS
1.3 Questions: The TLS Handshake: Client Hello message
1.3.1 What is the packet number in your trace that contains the TLS Client Hello message?
1.3.2 What version of TLS is your client running, as declared in the Client Hello message?
1.3.3 How many cipher suites are supported by your client, as declared in the Client Hello
message?
Hint: A cipher suite is a set of related cryptographic algorithms that determine how session keys will
be derived, and how data will be encrypted and be digitally signed via a HMAC algorithm.
1.3.4 Your client generates and sends a string of “random bytes” to the server in the Client
Hello message. What are the first two hexadecimal digits in the random bytes field
of the Client Hello message?
1.4 Questions: The TLS Handshake: Server Hello message 7
1.3.5 What is the purpose(s) of the “random bytes” field in the Client Hello message?
Note: you’ll have do some searching and reading to get the answer to this question; see for instance
RFC 5246 (section 8.1 in RFC 5246 in particular).
1.4 Questions: The TLS Handshake: Server Hello message
1.4.1 What is the packet number in your trace that contains the TLS Server Hello message?
1.4.2 Which cipher suite has been chosen by the server from among those offered in the
earlier Client Hello message?
1.4.3 Does the Server Hello message contain random bytes, similar to how the Client
Hello message contained random bytes? And if so, what is/are their purpose(s)?
In response to the initial Client Hello message, the server also sends back two important addi-
tional pieces of information (that may be contained in a different packet than the initial part of the
Server Hello message. The first important piece of information returned is a certificate issued by a
8 Chapter 1. TLS
trusted certification authority (CA; see section 8.3 in the text) that binds the public key (and other
information) of the web server to that web server’s identity. Your client may use the server’s public
key for a number of different purposes, including deriving the symmetric keys to encrypt data being
sent over this HTTPS/TLS/TCP session and for generating HMAC digital signatures. You can, of
course, look at the server’s certificate in Wireshark.
The second piece of additional information returned from the server are parameters needed for
the symmetric encryption of the data (HTTP messages in this case) being exchanged.
1.4.4 What is the packet number in your trace for the TLS message part that contains the
public key certificate for the www.cics.umass.edu server (actually the www.cs.umass.edu
server)?
1.4.5 A server may return more than one certificate. If more than one certificate is
returned, are all of these certificates for www.cs.umass.edu? If not all are for
www.cs.umass.edu, then who are these other certificates for? You can determine
who the certificate is for by checking the id-at-commonName field in the retuned
certificate.
1.4.6 What is the name of the certification authority that issued the certificate for id-
at-commonName=www.cs.umass.edu?
1.4 Questions: The TLS Handshake: Server Hello message 9
1.4.7 What digital signature algorithm is used by the CA to sign this certificate? Hint: this
information can be found in signature subfield of the SignedCertificate field of the
certificate for www.cs.umass.edu.
1.4.8 Let’s take a look at what a real public key looks like! What are the first four hexadec-
imal digits of the modulus of the public key being used by www.cics.umass.edu?
Enter the four hexadecimal digits.
Hint: this information can be found in subjectPublicKeyInfo subfield of the SignedCertificate
field of the certificate for www.cs.umass.edu.
1.4.9 Look in your trace to find messages between the client and a CA to get the CA’s
public key information, so that the client can verify that the CA-signed certificate
sent by the server is indeed valid and has not been forged or altered. Do you see
such message in your trace? If so, what is the number in the trace of the first packet
sent from your client to the CA? If not, explain why the client did not contact the CA.
10 Chapter 1. TLS
1.4.10 What is the packet number in your trace for the TLS message part that contains the
Server Hello Done TLS record?
1.5 Questions: The TLS Handshake: wrapping up the handshake
After the exchange of Hello messages, the client responds to the TLS Server Hello message with
its own public key information, a declaration (via a Change Cipher Spec record) that all further
communication will be encrypted via the negotiated algorithm and key, and an Encrypted Handshake
Message record that contains encrypted information (e.g., a cryptographic hash of all messages
exchanged during this handshake) to prevent man-in-the-middle replay attacks.
1.5.1 What is the packet number in your trace for the TLS message that contains the public
key information, Change Cipher Spec, and Encrypted Handshake message, being
sent from client to server?
1.5.2 Does the client provide its own CA-signed public key certificate back to the server?
If so, what is the packet number in your trace containing your client’s certificate?
Lastly, the server responds to the client with its own a declaration (via a Change Cipher Spec
record) that all further communication will be encrypted via the negotiated algorithm and key,
and an Encrypted Handshake Message record which also contains encrypted information (e.g., a
cryptographic hash of all messages exchanged during this handshake) to prevent man-in-the-middle
replay attacks.
1.6 Questions: Application data 11
1.6 Questions: Application data
1.6.1 What symmetric key cryptography algorithm is being used by the client and server
to encrypt application data (in this case, HTTP messages)?
1.6.2 In which of the TLS messages is this symmetric key cryptography algorithm finally
decided and declared?
1.6.3 What is the packet number in your trace for the first encrypted message carrying
application data from client to server?
1.6.4 What do you think the content of this encrypted application-data is, given that this
trace was generated by fetching the homepage of www.cics.umass.edu?
12 Chapter 1. TLS
1.6.5 What packet number contains the client-to-server TLS message that shuts down the
TLS connection? Because TLS messages are encrypted in our Wireshark traces, we
can’t actually look inside a TLS message and so we’ll have to make an educated
guess here.
