Beyond the Padlock 🔒: Demystifying TLS Handshake
The padlock in the URL bar. We see it countless times a day, yet its inner workings remain shrouded in mystery for many. Today, we're unlocking those secrets and diving headfirst into demystifying TLS
We visit a number of websites everyday and it is a pretty common sight to see a padlock in the URL bar of the browser. It is known that it offers security for the data transferred but the process involved is lost in abstractions. Most of the times even developers have very little knowledge on what happens behind the scenes. In this article let us try to understand how TLS works by taking the example of a ubiquitous protocol that has become synonymous with secure online interactions: HTTPS.
🔓 Unlocking the components
To understand TLS better let us first meet the key components involved.
Digital Certificates
Let us take a real world analogy to understand what Digital certificates are and what they have to offer in establishing a secure communication. Consider Digital Certificates as passports issues to citizens of country. The process of issuing a passport involves a vetting process to ensure the identity of a person and also the validity of the information provided, the passport is only issued upon successful verification. The passport once issued can be used to verify the identity and nationality of an individual. The entities to notice here are the passport authority (a trusted party), the individual and the passport.
Similarly, when accessing a website how do we make sure that the data we received is actually from the website we tried to contact. How do we make sure if the data we received is not from a malicious website that is impersonating the original website we are trying to access. Digital certificates here are used to verify the identity of a website. From the analogy above the role of a trusted party is played by a Certificate Authority which is responsible for verifying the identity of a website before issuing a Digital Certificate. The Digital certificate is comparable to the passport using which a website can prove it’s identity to the client trying to access it.
A digital certificate contains a public key of the server, a Digital signature signed by the CA and some metadata which includes the server name, validity and few other details (Refer for more information). The digital signature is added to the certificate as a proof that the CA vouches for the server’s identity. It is generated by generating the hash of the certificate body and then encrypting the hash with the private key of the CA. A client can verify the validity of the certificate by doing the same in reverse. Generate a hash of the certificate body (excluding the signature), and use the CA’s public key to decrypt the signature that is a part of the certificate. The generated hash should be the same as the hash obtained by decrypting the signature.
Public Key Cryptography
Public key cryptography enables secure key exchange which is later used for maintaining confidentiality of data at transit.
Symmetric Key Encryption
Symmetric key encryption algorithms are used to encrypt and decrypt data at transit.
Cipher Suites
A cipher suite is a set of cryptographic algorithms which helps establish a secure communication channel. Each algorithm of a suite deals with an aspect of cryptography. A Cipher Suite consists algorithms for:
Key Exchange
Authentication
Bulk Data Encryption (Confidentiality)
Message Authentication Code (Integrity)
It all starts with a handshake 🤝
A handshake is a process during which the client and the server exchange a series of messages to agree on the parameters of the subsequent communication. In a TLS handshake the client and the server should agree upon a cipher suite and based on the cipher suite selected the required information is exchanged and a secure connection is established.
Let us divide the entire handshake into the following phases:
Agree upon a Cipher Suite.
Server should authenticate itself with the client.
Both client and server should either exchange or deduce a session key. The mechanism depends on the key exchange algorithm from the cipher suite.
Establish a connection. Use a symmetric key encryption algorithm from the cipher suite along with the session key to encrypt the data in transit.
At the time of writing, TLS 1.2 and 1.3 are being used and the previous versions of TLS/SSL are marked deprecated. The handshake has pretty much remained the same from TLS 1.0-1.2 but has seen a design change in TLS 1.3.
TLS 1.2
Forward secrecy
Forward secrecy is a feature that protects encrypted sessions even if the long term secret keys are compromised. This is achieved using ephemeral secret keys for each connection which cannot be retrieved even if the master key is compromised.
ECDHE is an example of an algorithm that offers forward secrecy. Both the client and the server generate ephemeral key pair for each session. The ECDHE params that are exchanged as mentioned above contains the corresponding temporary public keys which are then used to deduce the secure session key.
RSA on the other hand is an algorithm which doesn’t offer forward secrecy. It makes use of the server’s master key pair to exchange the premaster secret. Client uses the server’s public key (made available with the certificate) to encrypt the premaster secret, both the client and the server uses the premaster key along with the random values shared at the begining of the handshake to generate a session key.
Handshake with RSA key exchange
The RSA key exchange algorithm is given less priority due to it’s lack of forward secrecy. The algorithms which provide perfect forward secrecy are given a higher priority when estalishing a TLS 1.2 connection.
The ClientHello, ServerHello and the Certificate messages remain unchanged and are the same as explained in ECDHE handshake. This is followed by the server sending the ServerHelloDone message. The notable difference from ECDHE is the absence of Server Key Exchange message.
Client Key Exchange: The client generates a premaster secret and encrypts it using the server’s public key and is sent to the server wrapped in this message.
Change Cipher Spec Message: The client sends this message to indicate that it has finished its part of the handshake. The server will now be waiting to receive a Encrypted Handshake Message.
Encrypted Handshake Message: The client builds a encrypted handshake message and it is done by taking a hash of ClientHello, ServerHello, Cerficate, Server Hello Done, Client KeyExchange messages appended together and encrypting the hash with the symmetric key generated. The hash is wrapped in a tls packet and sent to the server.
Verify and Establish connection: This is crucial step in the entire process because verifying the Encrypted Handshake Message ensures the integrity of the handshake and that is not tampered with by a man in the middle. Once the server verified this message the Application Data is encrypted and exchanged between the client and the server.
Handshake with ECDHE key exchange
ClientHello: The handshake starts with the client sending a client hello message to the server. This message contains the TLS version(1.2), a random value (client random), a list of supported cipher suites.
ServerHello: The server responds back with a server hello message. The contents include the most secure cipher suite from the list sent by the client (a cipher suite with ECDHE key exchange algorithm in this case) and a server random.
Certificate: The server sends the certificate to the client to prove its authenticity.
Server Key Exchange: The server also sends the ECDHE parameters that are essential for securely deducing the session key.
Server Hello Done: This message indicates that the server is done.
Client Key Exchange: The client does the same and replies back with ECDHE parameters.
Change Cipher Spec Message: The client sends this message to indicate that it has finished its part of the handshake. The server will now be waiting to receive a Encrypted Handshake Message.
Encrypted Handshake Message: The client builds a encrypted handshake message and it is done by taking a hash of ClientHello, ServerHello, Cerficate, KeyExchange, Server Hello Done messages appended together and encrypting the hash with the symmetric key generated using ECDHE. The hash is wrapped in a tls packet and sent to the server.
Verify and Establish connection: This is crucial step in the entire process because verifying the Encrypted Handshake Message ensures the integrity of the handshake and that is not tampered with by a man in the middle. Once the server verified this message the Application Data is encrypted and exchanged between the client and the server.
TLS 1.3
The notable features of TLS1.3 handshake are the shorter handshake for performance and security enhancements.
Handshake with ECDHE key exchange
ClientHello: The TLS1.3 client hello messages contains the version of TLS, a list of supported ciphers and the key exchange algorithm (the client guesses a key exchange algorithm that the server might pick). It also contains the parameters supported by the key exchange algorithm (Keyshare).
ServerHello: The sever responds back with serverhello containing the key exchange algorithm the server has picked, the parameters need for successful key exchange.
ChangeCipherSpec: The server then sends this message indicating client to switch to encrypted channel. Any communication following this message is over an encrypted channel.
Encrypted Extensions: TLS1.3 supports exchange of any sensitive extensions once the encrypted channels has been established through this message.
Certificate: The server then sends the certificate to the client.
Certificate Verify: The certificate verify message is sent to prove the ownership of the private key associated with the certificate. This is achieved by signing the hash of all the handshake messages up until this point. The signature can be verified on the client side by computing the hash and verifying the signature using the public key.
ServerFinished: The finished message contains the hash of the entire handshake up to this point.
ChangeCipherSpec: The client now sends this message indicating that any communication following this from the client would be over an encrypted channel.
ClientFinished: The client finished message contains hash of all the messages until this point.