Hello, if you have any need, please feel free to consult us, this is my wechat: wx91due

In this lab, we’ll investigate Transport Layer Security (known as TLS) and aspects of the authentication, data integrity, and confidentiality services provided by TLS.  TLS is the successor to the now-deprecated Secure Sockets Layer (SSL). So, it’d be preferable to do this v8.1 TLS Wireshark lab, rather than the v8.0 SSL Wireshark Lab. 

We’ll investigate TLS by analyzing a Wireshark packet trace captured during the retrieval of a web page via HTTPS - a secure version of HTTP, which implements TLS on top of HTTP.  We’ll look at TLS’s client-server handshaking protocol in some detail, since that’s where most of the interesting action happens.  You may want to review Section 8.6 in the text; useful online resources for learning more about TLS are here, here, and here; and, of course, in RFC 5246.   

1. Capturing packets in an TLS session

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

If you’re unable to run Wireshark on a live network connection, you can download a packet trace that was captured while following the steps above on one of the author’s computers .  In addition, you may well find it valuable to download this trace even if you’ve captured your own trace and use it, as well as your own trace, when you explore the questions below.

2.  A first look at the captured trace

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.  Your screen should look similar to what is shown in Figure 1.

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.

In answering the questions below, you can use either your own live trace, or use the Wireshark captured packet fileTLS-wireshark-trace1 in  http://gaia.cs.umass.edu/wireshark-labs/wireshark-traces-8.1.zip 

We’ve said earlier that HTTPS implements TLS running “over” TCP.  That means that a TCP connection must first be established between your browser and the web server for www.cics.umass.edu before TLS and HTTP messages can be exchanged, just as we saw with the vanilla (non-TLS) HTTP protocol.

1. What is the packet number in your trace that contains the initial TCP SYN message?  (By “packet number,” we meant the number in the “No.” column at the left of the Wireshark display, not the sequence number in the TCP segment itself).

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

3.  The TLS Handshake:Client Hello message

We learned that, as shown in Figure 2, the client-server TLS handshake begins with the client sending a TLSClient Hello message.

3. What is the packet number in your trace that contains the TLSClient Hello message?  

4. What version of TLS is your client running, as declared in theClient Hello message?

5. How many cipher suites are supported by your client, as declared in theClient Hello message?  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.

6. Your client generates and sends a string of “random bytes” to the server in theClient Hello message.  What are the first two hexadecimal digits in the random bytes field of theClient 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 theClient 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) 

3.  The TLS Handshake:Server Hello message

Next, let’s take a look at the second step of the TLS handshake, the TLSServer Hello message, which is sent in response to the earlier TLSClient Hello message.

8. What is the packet number in your trace that contains the TLSServer Hello message?  

9. Which cipher suite has been chosen by the server from among those offered in the earlierClient Hello message?  

10. Does theServer Hello message contain random bytes, similar to how theClient Hello message contained random bytes? And if so, what is/are their purpose(s)?

In response to the initialClient 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 theServer 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.

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.  

Let’s dig a bit deeper into the public key certificate.  

11. 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)?  

12. 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 whoare these other certificates for? You can determine who the certificate is for by checking the id-at-commonName field in the retuned certificate.  

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.

15. Let's take a look at what a real public key looks like! What are the first four hexadecimal digits of the modulus of the public key being used by www.cics.umass.edu? Enter the four hexadecimal digits (without spaces between the hex digits and without any leading '0x' , using lowercase letters where needed, and including any leading 0s after '0x').  Hint: this information can be found in subjectPublicKeyInfo subfield of the SignedCertificate field of the certificate for www.cs.umass.edu.

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

TheServer Hello message is always terminated by an explicitServer Hello Done record.

17. What is the packet number in your trace for the TLS message part that contains theServer Hello Done TLS record?  

4.  The TLS Handshake: wrapping up the handshake

After the exchange ofHello messages, the client responds to the TLSServer Hello message with its own public key information, a declaration (via aChange Cipher Spec record) that all further communication will be encrypted via the negotiated algorithm and key, and anEncrypted 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.

18. What is the packet number in your trace for the TLS message that contains the public key information,Change Cipher Spec,andEncrypted Handshake message, being sent from client to server?

19. 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 aChange Cipher Spec record) that all further communication will be encrypted via the negotiated algorithm and key, and anEncrypted 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.

5.  Application data

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)?

21. In which of the TLS messages is this symmetric key cryptography algorithm finally decided and declared?

22. What is the packet number in your trace for the first encrypted message carrying application data from client to server?

23. 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?

Note: Cipher suite - Wikipedia