You should startup wireshark and begin packet capture

Wireshark Lab: TLS v8.1

The first step in this lab is to capture the packets in an TLS session. To do this, you should startup Wireshark and begin packet capture, retrieve the homepage from https://www.cics.umass.edu using the browser of your choice, and then stop Wireshark packet capture. The ‘s’ after ‘http’ will cause the Hypertext Transfer Protocol Secure (HTTPS) - an extension of HTTP – to be used to securely retrieve the homepage from www.cics.umass.edu. Here, “securely” means that the www.cics.umass.edu server will be authenticated by your web browser, that the transmission of your client HTTP GET request and the server’s reply will be encrypted, and the integrity of all message content will be cryptographically verified. Of course, the authentication, integrity and encryption of a computer science department’s webpage may not be as critical as that for Internet commerce and banking sites, but the same TLS protocol and TLS messages are used in all cases.

in Wireshark’s display filter window. Your screen should look similar to what is shown in Figure 1.

Figure 1: Wireshark display showing TCP and TLS message to/from 128.119.240.84

It's important to keep in mind that an Ethernet frame (containing an IP datagram containing an TCP segment) may contain one or more TLS records. (This is very different from HTTP, for which each frame contains either one complete HTTP message or a portion of a HTTP message.) Also, a TLS record may not completely fit into an Ethernet frame, in which case multiple frames will be needed to carry the record.

2. Is the TCP connection set up before or after the first TLS message is sent from client to server?

Figure 2: TLS handshaking

3. The TLS Handshake: Client Hello message

6. 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?  Enter the two hexadecimal digits (without spaces between the hex digits and without any leading '0x' , using lowercase letters where needed).  Hint: be careful to fully dig into the Random field to find the Random Bytes subfield (do not consider the GMT UNIX Time subfield of Random).

7. 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 section 8.6 and in RFC 5246 (section 8.1 in RFC 5246 in particular).

10. 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 additional 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 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. You can also view the server’s certificate in your web browser after the www.cs.umass.edu server has responded to your request (and the certificate formatted a lot prettier too) – here’s how.

13. What is the name of the certification authority that issued the certificate for id-at-commonName=www.cs.umass.edu?

14. 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.

4. 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.

Once the TLS handshaking has completed, the encrypted application data can begin to flow over the HTTP-over-TLS-over-TCP connection. Of course, since this data is encrypted we can’t actually examine the contents of these encrypted messages (and isn’t that just the point!). But we can still ask a few last questions about the encrypted traffic.

20. What symmetric key cryptography algorithm is being used by the client and server to encrypt application data (in this case, HTTP messages)?

24. 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.