TLS Handshake
The process of establishing a TLS connection.
TLS Versions 1.0 - 1.2
Purpose of TLS:
- Confirm the identity of the server you’re connecting to (are they whom they say they are)
- Exchange necessary keys for an encrypted channel
- Create an encrypted communication channel between a client and a server (e.g. browser and a website)
1: Client Hello
Client sends a “Client Hello” record to the server with which it wants to connect.
This record contains:
- SSL Version Number
- A random piece of data
- Session ID
- A list of all cryptographic cyphers the client understands
- Extensions – not used so always blank.
SSL Version Number
This is the highest SSL version number the client supports. When the server responds, it will respond with its highest supported SSL version. This highest they both support will be used
Random Data
32 bytes of random data which will be mixed in with the final session keys later
Session ID
An identifier which can be used to resume a session later, to save having to renegotiate a connection
Cypher Suites
Long list of all the cypher suites the client can use
Extensions
Not used. Was included in the original design to allow for additional data to be sent in future versions without needing to rewrite the whole protocol. This is used in TLS1.3. Sent as plain text
Note
Over 300 cyphers supported but only about 20 considered secure. Only 5 suites are supported in TLS1.3
2: Server Hello
Server replies with a Server Hello record.
This record contains:
- SSL Version Number
- A random piece of data
- Session ID
- A list of all cryptographic cyphers the client understands
- Extensions – not used so always blank
SSL Version
As with the client, the highest number it supports. The remaining connection will proceed on the lowest of the ‘highest’ numbers between the client and server hello
Random Data
Another 32 bits of random data
Session ID
The server will either respond with the same session ID as the client, to confirm the session can be resumed, or a label for the current session, to allow for future resumption
Cypher Suites
The suite the server had chosen to use
Extensions
Would be a response to the extension, if any was sent.
Notes
Sent as plain text
The record fields are the same as for the Client Hello
4: Server certificate
The server starts a Diffie-Hellman Key Exchange by sharing a public value. This will be combined with the Client’s public key to create a shared secret between the Client and Server.
As part of the Key Exchange, the server will encrypt it’s public key with it’s private key. The server can then decrypt the public key, with the server’s advertised public key and compare them. This proves the server owns both it’s alleged private and public keys.
RSA key exchange can be used (in which case this step doesn’t exist). RSA is less secure and only needs the client value sent earlier.
This is sent as plain text.
5: Hello Done
Server sends Hello Done record. This is an empty record and indicates the server is done sending messages
6: Client Public Key
The client now sends its public key value, which means the Diffie-Helman calculation can be performed and a shared secret created by both the client and server. A master secret is created based on the data so far exchanged. A master secret is now calculated by both parties, combining the shared secret calculated above, the two shared random pieces of data and the string “master secret”.
Four session keys are created from the master secret: two symmetric encryption keys and two HMAC keys. A HMAC key is another encrypted key used to ensure that a man-in-the-middle can’t alter the keys without it being evident. Each symettirc key is used to encrypt the traffic in a specific direction (i.e. one used client –> server, one client <– server).
The HMACs are used to provide data integrity and use hashing algorithms like Poly1305, SHA384, SHA256. The symmetric keys provide data confidentiality and use a protocol like AES or ChaCha20/
7: Change Cypher
Client sends a Change Cipher Spec record – this is a blank record and indicated the next record will be encrypted. This doesn’t exist in TLS1.3 as it’s a bit pointless
8: Client Finished
Client sends a Finished record. This consists of a verification value it has created, which the server can also calculate, which it encrypts. The verification value is a hash of the master secret, the string “client finished” and a hash of all handshake records seen or sent (except the Change Cipher Spec record).
The server calculates and hashed the verification value and compares it’s hash with he one it received. This proves the client had the correct session keys and it “saw” the same handshake records
9: Server Change Cypher
The server sends a Change Cipher Spec record This again simply says the next record is encrypted. TLS1.3 does away with this as both parties already know that the messages are now encrypted
10: Server Finished
The server sends a Finished record. This consists of a server verification value - a hash of the master secret, the string “server finished” and a hash of all handshake records seen or sent (except the Change Cipher Spec record). This won’t include the Change Cipher Spec records, but will include the client verification value it received in (8)
The client now calculates and hashed the server verification record and compares them to see if they match. This proves the server had the correct session keys and both the client and server all “saw” the same handshake records. The handshake is now complete and encrypted data can be sent.
TLS 1.3
The key differences are:
- Only 5 cipher suites are now supported, all of which support perfect forward secrecy.
- The client hello is sent encrypted. This, and the reduced number of cipher suites mean:
- The extension in the client hello is used to send all the information, including the certificates, that the server needs for every cipher suite it supports (as there are 5 max) - No change cipher spec records are needed as they were a bit pointless and just took up time
- The session ID isn’t needed (so will always be blank, or zero) as TLS1.3 session can
- RSA can no longer be used for key exchanges.