- Consider the trace https://www.cloudshark.org/captures/2afbba90fdcb that captures an HTTPS session and answer the questions below. The trace captures encrypted traffic, so normally you would not be able to see the application layer payload. As the trace was taken, the browser (Chrome) was instructed (by starting it with
--ssl-key-log-file=sslkeylogfile.logoption) to save the SSL keylog for the session. The SSL keylog was then uploaded to CloudShark together with the trace to enable decryption. If you are curious how the same trace looks without the key, take a look at https://www.cloudshark.org/captures/21d4224a7346.
- The SSL keylog has been uploaded to a third-party website. Does that somehow compromise security of either the client or the server? Obviously, the content of the session is now visible to everyone but how about any past or future sessions? Or sessions with other clients or servers? Is there a danger of Man-in-the-Middle attack?
- How many packets does it take to establish the TLS session (i.e., past 3-way handshake all the way to the packet that carries the HTTP GET request)?
- How many round trips does it take to establish the TLS session, i.e., to get to the point when the client can start with HTTP? Pay attention to what is a trigger for what, this is a bit more complicated than counting packet pairs till you get to the one that contains the first HTTP command.
- Which packets contain the server certificate?
- Who issued the certificate?
- From the TCP perspective, is there an ACK for every data packet sent?
- What is the purpose of the last line of the HTTP request headers?