$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 $\text{'}0$ x $\text{'},$ using lowercase letters where needed, and including any leading $0$s after $\text{'}0$ x $\text{'}).$ 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 $\text{'}$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$.$ The Server Hello message is always terminated by an explicit Server Hello Done record. $17.$ What is the packet number in your trace for the TLS message part that contains the Server Hello Done TLS record? $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. $18.$ 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? $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 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.