TLS and SSH¶

Example: TLS 1.2 Handshake

The following full example shows a client being authenticated via TLS 1.2 using certificates exchanged between both peers.

1. Negotiation Phase:

   Client \(\Longrightarrow\) Server

   • A client sends a ClientHello message specifying
     • the highest TLS protocol version it supports
     • a random number, a list of suggested cipher suites and compression methods.

   Client \(\Longleftarrow\) Server

   • The server responds with a ServerHello message, containing
     • the chosen protocol version
     • a random number, cipher suite and compression method from the choices offered by the clien
     • (optional) a session id to perform a resumed handshake.
   • The server sends its Certificate message (may be omitted).
   • The server sends its ServerKeyExchange message (may be omitted)
   • (ONLY MUTUAL AUTH) The server sends a CertificateRequest message, to request a certificate from the client.
   • The server sends a ServerHelloDone message, indicating it is done with handshake negotiation.

   Client \(\Longleftarrow\) Server (same)

   • (ONLY MUTUAL AUTH) The client responds with a Certificate message, which contains the client's certificate, but not its private key.
   • The client sends a ClientKeyExchange message, which may contain a PreMasterSecret, public key, or nothing. (Again, this depends on the selected cipher.)
     • This PreMasterSecret is encrypted using the public key of the server certificate.
   • (ONLY MUTUAL AUTH) The client sends a CertificateVerify message, which is a signature over the previous handshake messages using the client's certificate's private key. This signature can be verified by using the client's certificate's public key.
     • prove that the client has access to the private key of the certificate and thus owns the certificate.
   • The client and server then use the random numbers and PreMasterSecret to compute a common secret, called the "master secret". All other key data ("session keys") for this connection is derived from this master secret (and the client- and server-generated random values), which is passed through a carefully designed pseudorandom function.

   Client \(\Longrightarrow\) Server

2. The client now sends a ChangeCipherSpec record, essentially telling the server, "Everything I tell you from now on will be authenticated (and encrypted if encryption was negotiated). "

   • The ChangeCipherSpec is itself a record-level protocol and has type 20 and not 22.
   • Finally, the client sends an encrypted Finished message, containing a hash and MAC over the previous handshake messages.
   • The server will attempt to decrypt the client's Finished message and verify the hash and MAC.
     • If the decryption or verification fails, the handshake is considered to have failed and the connection should be torn down.

   Client \(\Longleftarrow\) Server

3. Finally, the server sends a ChangeCipherSpec, telling the client, "Everything I tell you from now on will be authenticated (and encrypted if encryption was negotiated)."

   • The server sends its own encrypted Finished dmessage.
   • The client performs the same decryption and verification procedure as the server did in the previous step.

   Client \(\iff\) Server

4. Application phase: at this point, the "handshake" is complete and the application protocol is enabled, with content type of 23.

   • Application messages exchanged between client and server will also be encrypted exactly like in their Finished message.