The TLS Handshake:
Everything that happens between YOU and the WEBSITE you are visiting in order to get that coveted padlock. 🔒
Explained in a Twitter thread. 🧵
#ssl #tls #cybersecurity
Everything that happens between YOU and the WEBSITE you are visiting in order to get that coveted padlock. 🔒
Explained in a Twitter thread. 🧵
#ssl #tls #cybersecurity
As we go through this, keep in mind the goal of SSL / TLS:
A Client (your web browser) connects to a Server (a web site).
TLS does two things:
✅ Makes sure the Server is really who they say they are
✅ Establish Session Keys to protect the ensuing data transfer
1/
A Client (your web browser) connects to a Server (a web site).
TLS does two things:
✅ Makes sure the Server is really who they say they are
✅ Establish Session Keys to protect the ensuing data transfer
1/
Each record in the image is labeled with a number (1-10). This number is used as a reference in the explanations below.
Before we get into the Handshake itself, we have to briefly mention two things:
2/
Before we get into the Handshake itself, we have to briefly mention two things:
2/
Record != Packets
Each line above represents a “Record” sent in the TLS handshake. This is not the same as a Packet.
Sometimes multiple Records fit inside a single Packet, and other times multiple Packets are required to carry a single Record.
3/
Each line above represents a “Record” sent in the TLS handshake. This is not the same as a Packet.
Sometimes multiple Records fit inside a single Packet, and other times multiple Packets are required to carry a single Record.
3/
To truly understand the TLS Handshake, you should be familiar with the following Cryptography concepts:
Hashing -
MACs and HMACs -
Encryption -
Consider these as pre-requisites =)
4/
Hashing -
MACs and HMACs -
Encryption -
Consider these as pre-requisites =)
4/
1️⃣ Client Hello
The TLS Handshake starts with the Client sending a Client Hello. (in this context, the Client is your web browser)
Inside the Client Hello are 5 important fields:
* SSL Version
* Random Number
* Session ID
* Cipher Suites
* Extensions
5/
The TLS Handshake starts with the Client sending a Client Hello. (in this context, the Client is your web browser)
Inside the Client Hello are 5 important fields:
* SSL Version
* Random Number
* Session ID
* Cipher Suites
* Extensions
5/
1️⃣.1 -- SSL Version
The Client sends the highest version of SSL it supports.
The Server does the same in the next record. The Client and Server then proceed with the highest mutually supported version of SSL/TLS.
(note, this method of version negotiation changes in TLS 1.3)
The Client sends the highest version of SSL it supports.
The Server does the same in the next record. The Client and Server then proceed with the highest mutually supported version of SSL/TLS.
(note, this method of version negotiation changes in TLS 1.3)
1️⃣.2 -- Random Number
Client generates & shares 32 bytes of Random Data.
This will be “mixed in” to the final session keys which secure data between Client and Server.
This provides what Cryptography calls “entropy” -- additional "randomness” for the ensuing Session Keys.
Client generates & shares 32 bytes of Random Data.
This will be “mixed in” to the final session keys which secure data between Client and Server.
This provides what Cryptography calls “entropy” -- additional "randomness” for the ensuing Session Keys.
1️⃣.3 -- Session ID
SSL/TLS has a feature known as “Session Resumption”, this allows the Client and Server to resume an older session, avoiding the hard work of asymmetric encryption and key derivation.
This field is what the client uses to request an abbreviated handshake
8/
SSL/TLS has a feature known as “Session Resumption”, this allows the Client and Server to resume an older session, avoiding the hard work of asymmetric encryption and key derivation.
This field is what the client uses to request an abbreviated handshake
8/
1️⃣.4 -- Cipher Suites
A “Cipher Suite” specifies a specific algorithm for Authentication, Key Exchange, Symmetric Encryption & Hashing.
In this field, the Client sends a list of all Cipher Suites it supports.
More Details:
9/
A “Cipher Suite” specifies a specific algorithm for Authentication, Key Exchange, Symmetric Encryption & Hashing.
In this field, the Client sends a list of all Cipher Suites it supports.
More Details:
9/
1️⃣.5 -- Extensions
Extensions provide additional features that did not exist in the original RFC.
This allows updates to how the world does SSL/TLS without requiring an entire re-write of the protocol.
To keep it simple, we will proceed as if no extensions were included.
10/
Extensions provide additional features that did not exist in the original RFC.
This allows updates to how the world does SSL/TLS without requiring an entire re-write of the protocol.
To keep it simple, we will proceed as if no extensions were included.
10/
2️⃣ Server Hello
The Server then sends a Server Hello, which include these fields:
* SSL Version
* Random Number
* Session ID
* Cipher Suites
* Extensions
Notice they match the fields in the Client Hello.
The server is responding to what was offered by the client.
11/
The Server then sends a Server Hello, which include these fields:
* SSL Version
* Random Number
* Session ID
* Cipher Suites
* Extensions
Notice they match the fields in the Client Hello.
The server is responding to what was offered by the client.
11/
2️⃣.1 -- SSL Version
Server offers the highest version of SSL it supports – now both the Client & Server know the highest mutually supported version.
More information on the versions of SSL/TLS here:
-
-
12/
Server offers the highest version of SSL it supports – now both the Client & Server know the highest mutually supported version.
More information on the versions of SSL/TLS here:
-
-
12/
2️⃣.2 -- Random Number
Server also generates and shares 32 bytes of randomly generated data.
13/
Server also generates and shares 32 bytes of randomly generated data.
13/
2️⃣.3 -- Session ID
Server uses this field to either:
(A) Confirm the Client/Server are doing an abbreviated, resumed Session
(B) Assign a label to the current SSL/TLS session, for possible future Session Resumption
14/
Server uses this field to either:
(A) Confirm the Client/Server are doing an abbreviated, resumed Session
(B) Assign a label to the current SSL/TLS session, for possible future Session Resumption
14/
2️⃣.4 -- Cipher Suites
Server selects a Cipher Suite from the list offered by the Client.
Fun fact: in TLS 1.2 and prior there are 300+ possible Cipher Suites, and only 20~ are considered secure by modern standards.
TLS 1.3, thankfully, reduces the list to just 5!
15/
Server selects a Cipher Suite from the list offered by the Client.
Fun fact: in TLS 1.2 and prior there are 300+ possible Cipher Suites, and only 20~ are considered secure by modern standards.
TLS 1.3, thankfully, reduces the list to just 5!
15/
2️⃣.5 -- Extensions
In this field, the Server is responding to the various extensions offered by the Client in the Client Hello.
The general format for 1️⃣ and 2️⃣ is the Client offers something in the Client Hello, and the Server responds in the Server Hello.
16/
In this field, the Server is responding to the various extensions offered by the Client in the Client Hello.
The general format for 1️⃣ and 2️⃣ is the Client offers something in the Client Hello, and the Server responds in the Server Hello.
16/
3️⃣ Certificate
In this record, the Server sends it’s Certificate.
The Certificate acts as the Identity of the Server.
Specifically, it associates the Server’s Asymmetric Key Pair (Public & Private Key) with a specific identity (i.e., the website you are visiting)
17/
In this record, the Server sends it’s Certificate.
The Certificate acts as the Identity of the Server.
Specifically, it associates the Server’s Asymmetric Key Pair (Public & Private Key) with a specific identity (i.e., the website you are visiting)
17/
3️⃣ Certificate
Inside the Certificate is the Server's Public Key.
Shortly, the Server will send something that proves the Server has the matching Private Key.
This is how the Server's identity is validated -- TLS demands proof of ownership of the matching private key.
18/
Inside the Certificate is the Server's Public Key.
Shortly, the Server will send something that proves the Server has the matching Private Key.
This is how the Server's identity is validated -- TLS demands proof of ownership of the matching private key.
18/
4️⃣ Server Key Exchange
The Server starts a Diffie-Hellman Key Exchange by sharing a Public Value. This will be combined with the Client’s public value to create a secret value known only to the Client and Server.
More details on Diffie-Hellman:
19/
The Server starts a Diffie-Hellman Key Exchange by sharing a Public Value. This will be combined with the Client’s public value to create a secret value known only to the Client and Server.
More details on Diffie-Hellman:
19/
4️⃣ Notice, the DH Public Value is Signed.
This operation uses the Server’s Private Key, and is validated using the Server’s Public Key (from 3️⃣).
✅This proves that the Server is who they say they are, because (again) a Certificate links an identity to a specific Key Pair.
This operation uses the Server’s Private Key, and is validated using the Server’s Public Key (from 3️⃣).
✅This proves that the Server is who they say they are, because (again) a Certificate links an identity to a specific Key Pair.
4️⃣ Final Note about Key Exchanges (KX):
This handshake is illustrating a Diffie-Hellman KX, this is considered more secure than the alternative: RSA.
In an RSA KX, only the Client contributes a value and record 4️⃣ will not exist.
More info on RSA:
21/
This handshake is illustrating a Diffie-Hellman KX, this is considered more secure than the alternative: RSA.
In an RSA KX, only the Client contributes a value and record 4️⃣ will not exist.
More info on RSA:
21/
5️⃣ Server Hello Done
This is an empty message indicate the Server is finished sending records.
There are other SSL/TLS handshake variations in which the Server sends more records. The Server Hello Done record sent here indicates this handshake is NOT one of those variants.
22/
This is an empty message indicate the Server is finished sending records.
There are other SSL/TLS handshake variations in which the Server sends more records. The Server Hello Done record sent here indicates this handshake is NOT one of those variants.
22/
6️⃣ Client Key Exchange
In this record, the Client is sharing their half of the Diffie-Hellman Key Exchange by sharing their DH Public Value.
After receiving this record, both parties can perform the Diffie-Hellman calculation and create the Shared Secret.
23/39
In this record, the Client is sharing their half of the Diffie-Hellman Key Exchange by sharing their DH Public Value.
After receiving this record, both parties can perform the Diffie-Hellman calculation and create the Shared Secret.
23/39
<<twitter maximum thread reached, continuing shortly...>>
*️⃣ At this point two things are true:
- The Server’s identity has been verified thanks to the Signature from the Server Key Exchange.
- Both Client & Server have completed the DH Key Exchange and calculated the Shared Secret. In theory, no one else knows the Shared Secret.
- The Server’s identity has been verified thanks to the Signature from the Server Key Exchange.
- Both Client & Server have completed the DH Key Exchange and calculated the Shared Secret. In theory, no one else knows the Shared Secret.
*️⃣ The Master Secret is created by combining four values:
- Shared Secret (result of DH KX)
- Client Random Number from 1️⃣
- Server Random Number from 2️⃣
- string "master secret"
The result is the "Master Secret" which is used to generate the Session Keys that will protect data
- Shared Secret (result of DH KX)
- Client Random Number from 1️⃣
- Server Random Number from 2️⃣
- string "master secret"
The result is the "Master Secret" which is used to generate the Session Keys that will protect data
*️⃣ The Master Secret is used to generate 4 Session Keys 🔑:
- Two Symmetric Encryption Keys
- Two HMAC Keys
These keys are the ones that actually secure and encrypt the ensuing Application Data.
One set of Keys secure data in each direction:
C ---> S
C <--- S
26/
- Two Symmetric Encryption Keys
- Two HMAC Keys
These keys are the ones that actually secure and encrypt the ensuing Application Data.
One set of Keys secure data in each direction:
C ---> S
C <--- S
26/
*️⃣ The Symmetric Encryption Keys will be used to provide Data Confidentiality using a protocol like AES or ChaCha20
The HMAC Keys will be used to provide Data Integrity using hashing algorithms like SHA256, SHA384, and Poly1305.
More info:
27/
The HMAC Keys will be used to provide Data Integrity using hashing algorithms like SHA256, SHA384, and Poly1305.
More info:
27/
*️⃣ All that is left is for the Client and Server to prove to each other they each have the correct Session Keys.
They do this by sending the ensuing "Change Cipher Spec" record and "Finished" record.
Of these, the "Finished" record is the important one.
28/39
They do this by sending the ensuing "Change Cipher Spec" record and "Finished" record.
Of these, the "Finished" record is the important one.
28/39
7️⃣ Change Cipher Spec (Client)
This is an empty record which merely indicates that the next record is encrypted.
The Change Cipher Spec record is somewhat unnecessary, and no longer exists in TLS 1.3 (the latest version of SSL/TLS)
29/39
This is an empty record which merely indicates that the next record is encrypted.
The Change Cipher Spec record is somewhat unnecessary, and no longer exists in TLS 1.3 (the latest version of SSL/TLS)
29/39
8️⃣.1 Finished (Client)
The Client encrypts a “Verification Value” and sends it to the Server.
The Verification Value is a hash of:
- Master Secret
- string "client finished"
- Hash of all handshake records seen or sent (except C.C.S.)
30/
The Client encrypts a “Verification Value” and sends it to the Server.
The Verification Value is a hash of:
- Master Secret
- string "client finished"
- Hash of all handshake records seen or sent (except C.C.S.)
30/
8️⃣.2 Finished (Client)
The Server calculates the same Verification Value, and decrypts what was sent by the client.
If the results match, this proves to the Server:
- the client had the correct session keys ✅
- the client and server “saw” the same handshake records
31/
The Server calculates the same Verification Value, and decrypts what was sent by the client.
If the results match, this proves to the Server:
- the client had the correct session keys ✅
- the client and server “saw” the same handshake records
31/
9️⃣ Change Cipher Spec (Server)
Again, this record simply indicates that the next record is encrypted.
TLS 1.3 removes this record, as both parties know by protocol design that the remaining messages are encrypted.
32/
Again, this record simply indicates that the next record is encrypted.
TLS 1.3 removes this record, as both parties know by protocol design that the remaining messages are encrypted.
32/
🔟.1 Finished (Server)
The Server encrypts their own “Verification Value” and sends it to the Client.
This Verification Value is a hash of:
- Master Secret
- string "server finished"
- Hash of handshake records seen or sent (except C.C.S.)
(this handshake hash includes 8️⃣)
The Server encrypts their own “Verification Value” and sends it to the Client.
This Verification Value is a hash of:
- Master Secret
- string "server finished"
- Hash of handshake records seen or sent (except C.C.S.)
(this handshake hash includes 8️⃣)
🔟.2 Finished (Server)
The Client calculates the same Verification Value and decrypts what was sent by the Server.
If the results match, this proves to the Client:
- the server has the correct session keys ✅
- the server and client “saw” the same handshake records
34/
The Client calculates the same Verification Value and decrypts what was sent by the Server.
If the results match, this proves to the Client:
- the server has the correct session keys ✅
- the server and client “saw” the same handshake records
34/
🅰️ At this point, the Client and Server have verified the Server’s Identity and Established mutual Session Keys – which means the TLS Handshake is finally complete! 🔒
Now they can start sending Application Data, protected by the keys derived from the TLS Handshake
🎉🎇🎆✨🥳
Now they can start sending Application Data, protected by the keys derived from the TLS Handshake
🎉🎇🎆✨🥳
And to think… all this happens in the first few milliseconds *every* time you browse to an HTTPS website, or connect to an SSL VPN.
Prefer video lessons? Want to go even deeper? Here is the lesson from my TLS course where I unpack the TLS Handshake:
Prefer video lessons? Want to go even deeper? Here is the lesson from my TLS course where I unpack the TLS Handshake:
The thread above covered the TLS Handshake for TLS 1.2 (and prior).
But TLS 1.3 is now upon us… and brings about a LOT of changes!
Want to explore the full depth of TLS and SSL, including the new version? Then check out my Practical TLS Course:
pracnet.net/tls
But TLS 1.3 is now upon us… and brings about a LOT of changes!
Want to explore the full depth of TLS and SSL, including the new version? Then check out my Practical TLS Course:
pracnet.net/tls
As a bonus, I marked the course to the lowest price it has ever been while I’m updating the course with TLS 1.3 content.
If you work with TLS in any capacity, take advantage of this offer while it still lasts. There are only 2 lessons left =).
38/39
If you work with TLS in any capacity, take advantage of this offer while it still lasts. There are only 2 lessons left =).
38/39
Hope you enjoyed this Twitter Thread. You can find more Network Engineering and Network Security content on my blog and Youtube channel:
PracticalNetworking.net
youtube.com/practicalnetwo…
Or perhaps you'd also enjoy my last Twitter Thread:
39/39
PracticalNetworking.net
youtube.com/practicalnetwo…
Or perhaps you'd also enjoy my last Twitter Thread:
https://twitter.com/ed_pracnet/status/1511036090882220037
39/39
• • •
Missing some Tweet in this thread? You can try to
force a refresh
