TLS v1.2 handshake overview
A simplified walkthrough of TLS version 1.2 handshake using packet level data
Transport Layer Security protocol is one of the most prevalent encryption protocols on the web. It protects users of the web by ensuring confidentiality and integrity of the data flowing between browsers and web server. In this post, I am going to cover details of the handshake protocol (a sub-protocol) in TLS version 1.2. This post is inspired by a similar but more detailed post by Jeff Moser which can be found here. Jeff’s post is from 2009 and it covers TLS 1.0 handshake. So, I decided to revive it in my own way. Please be advised that knowledge of common cryptographic concepts and algorithms is required to fully understand the details given below. So let’s dive into it.
All handshaking sub-protocols (Alert, Change Cipher Spec and Handshake) in TLS 1.2 have been specified in RFC 5246. That document is the main reference for this post. While the main focus of this article is the handshaking protocol, I will also explicitly mention an important operation in TLS record protocol.
In each of the following screenshots, the data relevant to this post has been marked using red arrows.
Client Hello
If the client (web browser or mobile application ) initiates a TLS handshake, it sends the following important parameters in a “client hello” message:
- Random Bytes : Random bytes should generated by the client using a secure random number generator. The source of entropy for random number generation will depend on operating system and implementation of the client software.
- Session ID : If a TLS session was established between the client and the server in the past, this identifier may have the previous session ID value, which may be used to update the cryptographic parameters of this session. For a new session, this field is blank as shown in the screenshot.
- Cipher Suite List: Client also sends a list of cipher suites it supports in the order of preference. So, in this case, the client’s most favored cipher suite is TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256. However, as the server is going to select the second cipher suite in that order (as we will see in next step), let’s take a look at TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256.
Also note that there is a field called as “version” (above “Random” field), which should always represent the latest protocol version supported by the client.
Server Hello
As shown in the above diagram , the server responds to client hello because it has support for at least one protocol version and cipher suite present in the list sent by the client.
- Random : A random number generated by the server, independently of the client.
- Version and Cipher Suite : In this case, the server selected the second most preferred cipher suite indicated by the client, TLS 1.2 with TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256.
- Session ID : As this is a new connection, session ID is blank.
Server Certificate
After “server hello” is done, the server must send a certificate (or chain of certificates) that can be cryptographically verified by one of the root Certificate Authority (CA) certificates present in browser or mobile devices. As shown in the figure above, three certificates were sent by google’s server. Here is a screenshot of the above certificate chain as shown in Chrome browser for www.google.com
Certificate Authority based Public Key Infrastructure (PKI) is a huge topic but I am going to briefly describe what happens when browser receives the certificate for a server. CA based PKI combined with TLS protocol provides good security. Implicit trust is placed on the root Certificate Authorities. Please note the certificate verification step described in the paragraph is not a part of the TLS protocol.
The “encrypted” field is actually a digital signature associated with the first certificate. Note that the “algorithmIdentifier” field above “encrypted” field says sha256WithRSAEncryption. It means that the SHA-256 hash value of the first certificate was signed using RSA (private) key of the certificate authority in the certificate above it (Google Internet Authority G2). Browser verifies the signature by using the corresponding public key embedded in the (Google Internet Authority G2) certificate. Same verification step is continued until the CA certificate just below the root CA. There is no verification required for the root CA certificate as it trusted implicitly by the browser. Please note that the “algorithmIdentifier” value is not related to the “cipher suite” described earlier. Now, it's important at this time to highlight one field in this message. The public key embedded in the first certificate in the certificate chain is shown in the diagram below :
This certificate contains RSA public key of the www.google.com server (and related mathematical parameters) because the server selected cipher suite that contains RSA as digital signature algorithm. This public key will be used for digital signature purpose in later steps of the handshake.
Server Key Exchange & Server Hello Done
The next step in the handshake protocol is exchanging parameters for generating a symmetric key to encrypt all future application data. As the server and client agreed upon using Elliptic Curve Diffie- Hellman Ephemeral (ECDHE), they need to exchange public parameters used in ECDHE algorithm. The cryptographic details are out of scope here. However, note the three highlighted values sent here:
- Named Curve: The elliptic curve selected by server for the computation.
- Public Key: The server’s public component to be used by the client.
- Signature: The values are signed by using the private RSA key of the server so that the client can verify (using corresponding public key in the certificate) that the ECDHE parameter indeed came from the server its talking to and not an attacker.
The “Server Hello done” message is quite self-explanatory. It indicates end of “Server Hello” messages.
Client Key Exchange / Change Cipher Spec /Encrypted handshake
Client Key Exchange
The “Client Key Exchange” contains the client’s public parameters for ECDHE algorithm. Client parameter is not signed in this case.
Now, before we look into other messages in the above screenshot, let’s first take a look at how the client and server generate the secret key (called as master secret). As per section 8.1 RFC 5246, the formula for master_secret is given below:
master_secret = PRF(pre_master_secret, "master secret",
ClientHello.random + ServerHello.random)The pre_master_secret mentioned above is actually the key calculated by both server and client using ECDHE algorithm. The Pseudo Random Function (PRF) is actually HMAC-SHA256 . ClientHello.random and ServerHello.random are the random values generated and exchanged by client and server respectively, during initial hello messages. The string “master secret” is also used in the PRF. The master_secret is 48 bytes long.
At this point, it is important to point out one operation on the master_secret that is carried out in TLS record protocol. TLS record protocol is a separate sub-protocol which is used to actually encrypt and transmit upper level protocol data such as HTTP. The master secret is “expanded” into more secrets using a PRF in the TLS record protocol. The keys derived from master_secret are named as follows in the section 6.3 of RFC specification :
client_write_MAC_key[SecurityParameters.mac_key_length]
server_write_MAC_key[SecurityParameters.mac_key_length]
client_write_key[SecurityParameters.enc_key_length]
server_write_key[SecurityParameters.enc_key_length]
client_write_IV[SecurityParameters.fixed_iv_length]
server_write_IV[SecurityParameters.fixed_iv_length]As one can guess, the “write keys” are used for encrypting data. The “write MAC” keys are used for computing MACs of application level data. The Initialization Vectors (IVs) are computed only if needed by the cipher suite. As both client and server have all of these keys, they can decrypt and verify the integrity of the messages.
Change Cipher Spec
Change Cipher Spec is a separate sub-protocol in TLS which is used to indicate either party in TLS negotiation that the subsequent messages will be sent encrypted using the negotiated key and algorithm.
Encrypted Handshake Message (Finished Message)
Some of you might be wondering about the possibilities of Man-In-The-Middle the attacks during the handshake messages. For example, what if an attacker alters the cipher suites list sent by the client to make the server select a relatively weaker cipher suite ? TLS protocol does protect against MITM attacks using Finished Message, which is sent right after the Change Cipher Spec message.
The “Encrypted Handshake Message” in the screenshot will be a HMAC-SHA256 of
- master_secret
- hash of all the previous handshake messages (from ClientHello up to Finished message, not including this Finished Message)
- finished_label string (“client finished” for client message and “server finished” for server message) }
verify_data
PRF(master_secret, finished_label, Hash(handshake_messages))(quoted from section 7.4.9 of RFC 5246)
If the server or client are not able to verify the integrity of the handshake messages, the TLS handshake fails.
Encrypted Application Data
Until TLS 1.2, “MAC-then-Encrypt” technique is used to encrypt and protect integrity of data from upper layers (TLS record protocol). First, a MAC of the message is created using client_write_MAC_key by client and or server_write_MAC_key by server. After this, the actual data and MAC is encrypted using the client_write_key or server_write_key by the client and server respectively.
If you want to see the packet level data by yourself, you can use the .pcap file uploaded here. After opening the file, you can use type “ssl” as the filter in wireshark and then look at packet #37 through #43.
Any constructive criticism on this post is always welcome :) Thank you.