Decipher TLS 1.2 Handshake Messages (Wireshark)

Decipher TLS 1.2 Handshake Messages (Wireshark)

The TLS 1.2 Handshake: Step by Step

The exact steps within a TLS handshake will vary depending upon the kind of key exchange algorithm used and the cipher suites supported by both sides.

The RSA key exchange algorithm

The RSA key exchange algorithm is used most often. It goes as follows:

0. [Server] “Hello Request” message

• A message to notify the client to start initiate new negotiation process
  • In response, the client will send a “Client Hello” message when convenient.

1. [Client] “Client Hello” message
   • Version: TLS 1.2
     • The TLS protocol version that client wishes to communicate during this session
     • *Note: This parameter is the one inside the Handshake Protocol, NOT the one inside the Record Layer
   • Random: 623ca561799c5b0535f90d6740672bfc78c87063f9dc4d977422d4e370504f8c
     • “Client Random”, 32-bytes securely generated random number
   • Session ID: a3390344476d3f7609b868cc0f26a526b831b9e54d10345d1ff52456e754855e
     • The ID of a session the client wishes to use for this connection
     • Empty if no session id is available, or if the client wishes to generate new security parameters
   • Cipher suites: (16 suites) …
     • List of the cryptographic options supported by the client, sorted by client preference
   • Compression Methods: null
     • List of the compression methods supported by the client, sorted by client preference
   • Extensions: (10 extensions) …
     • Client’s supported extended functionality (offers to server)
   • Extension: renegotiation info
     • Client supports Secure Renegotiation
   • Extension: extended_master_secret
     • Signal server to use the extended master secret computation
2. [Server] “Sever Hello” message
   • Version: TLS 1.2
     • The TLS protocol version
     • *Note: This parameter is the one inside the Handshake Protocol, NOT the one inside Record Layer
   • Random: 4705f4786fcf658250dfb334f4450ca05e32069ef948799bc8d5e81946bb28cc
     • “Server Random”, 32-bytes securely generated random number
   • Session ID: d208d422264d4807bbd0fa2b8e95f08c525928b3181d949765c2bb655e25409f
     • This is the identity of the session corresponding to this connection
   • Cipher suite: TLS_RSA_WITH_AES_128_CBC_SHA
     • The single cipher suite selected by the server from the client’s list
   • Compression Methods: null
     • The single compression algorithm selected by the server from the client’s list
   • Extensions: (2 extensions) ...
     • Server’s supported extended functionality (based on client’s offer)
   • Extension: renegotiation info
     • Server supports Secure Renegotiation
   • Extension: extended_master_secret
     • Signal client to use the extended master secret computation
3. [Server] “Certificate” message.
   • Certificates
     • An optional message, required if the key exchange method uses certificates for authentication. Examples: RSA, DH_DSS, DH_RSA, DHE_DSS_DHE_RSA.
     • Not required for anonymous negotiation. Example: DH_anon
     • Most of the SSL/TLS implementation uses certificate for server authentication.
       • > Includes server’s certificate
       • > If available, includes intermediate CA certificate(s), root CA certificate
   • Certificate: server’s certificate
     • version: v3 (X.509)
     • serialNumber: 328585510
     • signature: SHA-256 (bit) with RSA Encryption
     • issuer: countryName, stateOrProvinceName, localityName, organizationName, organizationUnitName, commonName, emailAddress
     • validity: notBefore, notAfter
     • subject: countryName, stateOrProvinceName, localityName, organizationName, organizationUnitName, commonName, emailAddress
     • subjectPublicKeyInfo: algorithm (RSA 2048-bit), PublicKey (2048-bit in hex)
     • encrypted: (Digital Signature, 2048-bit in hex)
4. [Server] “Certificate Status” message.
   • An optional message, for server to provide the current status of its certificate.
   • Client that support a certificate status protocol like OCSP may includes the “status_request” extension in the “Client Hello” message (a.k.a “OCSP stapling”).
   • Server that support the same protocol may return a suitable certificate status response message, which is “Certificate Status” message.
   • Certificate status (example)
     • Certificate Status Type: OCSP
     • OCSP Response Status: successful
     • tbsResponseData: ID: Entrust Validation Authority
     • tbsResponseData: produceAt: Date & time
     • OCSP response’s Signature + Algorithm
     • Certificate (Entrust Validation Authority): Public Key + CA Signature
   • In this case, the server doesn’t send this message
5. [Server] “Server Key Exchange” message.
   • An optional message, only required for certain key exchange methods (Diffie-Hellman)
     • Required because “Certificate” message doesn’t contain enough data to allow the client to exchange a premaster secret.
       • > Required for: DHE_DSS, DHE_RSA, DH_anon.
       • > NOT required for: RSA, DH_DSS, DH.
   • The server provides additional cryptographic information
     • The prime modulus for DH operation
     • The generator used for DH operation
     • The server’s DH public key
   • In this case, it uses RSA, so this message is not sent by the server
6. [Server] “Certificate Request” message.
   • A non-anonymous server can optionally request a certificate from the client, if appropriate for the selected cipher suite.
     • certificate_types
     • supported_signature_algorithms
     • certificate_authorities
   • In this case, the server doesn’t send this message
7. [Server] “Server Hello Done” message.
   • Sent by the server to indicate the end of the ServerHello and associated messages.
8. [Client] “Certificate” message.
   • Certificates
     • An optional message, required if the server requests a certificate.
     • If the client doesn’t have suitable certificate, this message is sent but empty
   • Certificate: client’s certificate
   • In this case, the server doesn’t require the client to send this message
9. [Client] “Client Key Exchange” message.
   • The perform key exchange of the premaster secret so each side can independently derive the master secret.
   • There are 2 variant of key exchange algorithm:
     • RSA: This message will contain encrypted premaster secret
     • DH: This message will contain client’s DH public key
   • RSA Encrypted PreMaster Secret
     • 256-bytes encrypted string in hex
10. [Client] “Certificate Verify” message.
    • An optional message, sent if the client certificate has signing capability
    • This is used to provide explicit verification of a client certificate.
    • Client send the Digital Signature that is computed using its private key over all previous handshake messages, starting at “Client Hello” up to (but not including) this “Certificate Verify” message.
    • The server then validate the Digital Signature by using public key from the certificate that was provided by the client (client “Certificate” message).
    • In this case, the server doesn’t require the client to send this message
11. [Client] “Change Cipher Spec” message.
    • A signaling message to notify the receiving party that subsequent records will be protected under the newly negotiated CipherSpec and keys.
12. [Client] “Finished” message.
    • The Finished message is the first protected message with the just negotiated algorithms, and master secret key.
      • It is covered by the integrity check and the encryption
    • It includes a cryptographic checksum computed over all previous handshake messages (from both the client and server).
    • It obtains a proof that it has indeed talked to the same client all along.
      • This message protects the handshake from alterations
      • The attacker cannot modify the handshake messages and still get the Finished message right
    • Recipients of Finished messages MUST verify that the contents are correct.
      • Once a side has sent its Finished message and received and validated the Finished message from its peer.
      • It may begin to send and receive application data over the connection.
13. [Client] “Change Cipher Spec” message.
    • Now it’s the server’s turn to do the same. It decrypts the pre-master secret and computes the session key. Then it sends its “Change Cipher Spec” message to indicate it is switching to encrypted communication.
14. [Client] “Finished” message.
    • The server sends its “Finished” message using the symmetric session key it just generated, it also performs the same check-sum to verify the integrity of the handshake.

[Client] <–> [Server] “Application Data” message.

• Application data messages are carried by the record layer and are fragmented, compressed, and encrypted based on the current connection state.
• Encrypted HTTP messages