TLS Handshake : Under The Hood
--
TLS which is the successor of SSL is a protocol that provides a secure mechanism for authentication using x509 certificates. It also provides a two-way encrypted channel between two parties. Two way encryption means that TLS client can encrypt data to unreadable form and upon receiving, TLS server can decrypt it back to readable form such that any third party entity cannot eavesdrop on the conversation.
The TLS specification defines two protocols — The record protocol and the handshake protocol. Out of them, the handshake protocol is used to negotiate and set up a secure, encrypted channel between the client and the server. This helps in achieving both confidentiality and authenticity among the two parties by allowing them to verify each other, negotiate cipher suites and other parameters required to establish a secure connection.
The handshake protocol involves four sets of messages that are exchanged between the client and server before establishing the encrypted communication channel as depicted in the diagram below. Each set is typically transmitted in a separate TCP segment.
Client — ClientHello
The handshake is initiated when the client sends a ‘ClientHello’ message. The most important elements in this message are as follows.
- TLS version used by the client
- Cipher suites that the client supports
- List of compression methods
- List of extensions
- A random string that will be used later for generating cryptographic keys
The cipher suite consists of a code that represents four parameters: the authentication algorithm, key exchange method, encryption cipher and hashing algorithm. The client lists these cipher suites in its preferred order. Furthermore, instead of authenticating each time, client can restart a previous session through the inclusion of a ‘SessionId’ field.
Server — ServerHello
The server replies to client with a ‘ServerHello’ message, which contains its choice of cipher from the client’s preferred list and a random string, to be used later when generating cryptographic keys. However if the server does not agree with either of the cipher choices listed by the client, it will send a “Handshake Failure” message and terminate the connection.
Server — Certificate
Next, the server sends its certificate or a certificate chain which is also known as the certification path. The certificate is the server’s proof of identify so the client can authenticate the server. The certificate includes a digital signature that binds together server’s public key with its own identity. Usually, a certificate will by a trusted entity known as Certificate Authorities (CA). And the signature of the CA that the signed the certificate will be included in the certificate. There are also self-signed certificates which are signed by the server’s private key itself, not from a private key of a trusted CA.
A certificate chain is a list of certificates. The chain begins with the certificate of the server, and each corresponding certificate in the chain is signed by the entity identified by the next certificate in the chain. The chain terminates with a root CA certificate. The root CA certificate is always signed by the CA itself.
Both the client and server will maintain certificate repositories which are also known as truststores which contains a list of CA certificates that each of them trusts.
Therefore when the client receives the server’s certificate it will examines the certificate and if it is valid and digitally signed by a Certificate Authority (CA) that the client trusts, the server will be successfully authenticated. In case a certificate chain is sent, the signatures of all certificates in the chain must be verified by the client until the root CA certificate is reached.
Following diagram indicates the elements of a CA signed digital certificate.
A certificate validation process ensures the following.
* Certificate has not expired
The client checks the server certificate’s validity period (time period within Not Before and Not After). If the present date and time are outside of that range, it indicates that the server certificate has expired. Therefore the authentication process does not continue.
* The issuer of the server certificate is a trusted CA of client
Each client that supports TLS will maintain certificate repository containing a list of trusted CA certificates. This list decides which server certificates the client accepts. If the distinguished name (DN) of the ‘Issuer’ field matches the DN of a CA on the client’s certificate repository, the authentication process will continue. Also if the server has sent a certificate chain, the client will check each and every intermediate certificate up until the root certificate in the list until it finds a CA that is available in the client’s truststore.
* Issuer’s digital signature contained in server certificate is valid
The client uses the public key from the CA’s certificate (which it found in its list of trusted CAs in the previous step) to validate the CA’s digital signature on the server certificate. If the certificate content has changed after it was signed by the CA or, if the CA certificate’s public key doesn’t correspond to the private key used by the CA to sign the server certificate, the server authentication will fail. If the CA’s digital signature can be validated, the client has confirmed that the server certificate is valid.
Following diagram illustrates this validation process.
The server certificate is signed with the private key of the CA. Therefore the client will obtain the the Issuer’s DN from the server certificate and looks up on its certificate repository to validate whether the issuer CA is trusted by the client. If its trusted, the validation process is completed at this point. Otherwise, client will check the next immediate certificate in the certificate chain to identify issuer in that certificate. Once identified client will use the public key found in issuer’s certificate to verify the issuer’s signature in server certificate. This process is repeated until the client finds a certificate issued by a trusted CA in the chain. The last certificate in the chain is the Root CA certificate. Root CA certificate will be signed by its own private key. Therefore, Root CA signature will be validated with its own public key. However if the client cannot find the root CA certificate in its trust-store, the validation process will fail.
Tip: If you get the following error when you access a web-site in browser, it means that the certificate is either self-signed, unsigned or not signed by a trusted CA, Therefore the browser warn the user that the identity of the server cannot be properly verified.
* The domain name on the certificate matches the domain of the server
This step confirms that the server is actually located at the same network address specified by the domain name in the server certificate. This is also known as ‘Host name verification’. It prevents security attacks known as man-in-the-middle. Please refer [1] for further information regarding this.
* Certificate is not revoked (Optional)
Additionally, some clients may confirm that the certificate has not been revoked by using either OCSP or Certificate Revocation Lists.
Server — ServerKeyExchange
This message carries the keys exchange algorithm parameters that the client needs from the server in order to derive intermiate secrets that will be utilized when constructing the final session keys for symmetric encryption by both parties. It is optional, since some key exchange algorithms such as RSA key exchange does not require these parameters, because the server’s certificate itself will be enough for the client to construct and securely communicate the pre-master secret with the server.
E.g. if the method of key exchange chosen by the server in a previous step is Diffie–Hellman (DH), the server includes this message after the certificate, which will include the public components required to generate the master secret.
Server — CertificateRequest
This message will be sent, if SSL client authentication is enabled in the server. This is normally not required in most of the web servers, but for high security requirements, the server may require the client’s certificate for authentication. Along with the certificate request, the sever sends the client types that are acceptable and also indicates a list of Distinguished Names of Certificate Authorities that are trusted by the server. This list includes the CA authorities available in the server’s truststore.
Server — ServerHelloDone
Finally, the server sends the ServerHelloDone message indicating to the client that the server is finished passing security parameters. This message finishes the server’s part of the handshake negotiation. This message will not carry any other information.
Client — Certificate
The client responds with a Client Certificate if the server requests for client authentication with Certificate Request message. However before the sending the certificate, client will check the issuer’s DN of client’s certificate can be found in the list of Distinguished Names of trusted CAs sent by the server. If the issuer’s DN was not found, client will not send its certificate to the server. In the server side if client certificate authentication is mandatory, the TLS handshake will fail here. Otherwise, client will send its certificate and any needed intermediate certificates that chain to the matched DN listed in the Certificate Request message.
Client — ClientKeyExchange
The ClientKeyExchange message contains the pre-master secret, which is generated by the client. This is conducted according to the cipher suite aggreed by both parties in a previous step. Both the client and the server will use this to generate a master secret from which they both will derive the final cryptographic keys required to establish the encypted channel. The client encrypts the pre-master secret with the server’s public key such that if an eavesdropper were to intercept this bit of data he will not be able to decrypt it since he does not have access to the server’s private key. The master key provides the server with the required data to generate the keys for the symmetric encryption. However, if the cipher suite chosen for this session was DH, then the ClientKeyExchange contains the client’s public DH parameters instead of a pre-master secret.
Client — CertificateVerify
This message is used by the client to prove the server that it possesses the private key corresponding to its public key certificate. The message holds hashed information (hash of all the messages exchanged so far during the handshake process) which is digitally signed by the client. It is required if the server issued a CertificateRequest to the client, so that client has sent a certificate in response whic needs to be verified in server side.
Client — ChangeCipherSpec
The ChangeCipherSpec message is just a message from the client to inform the server that all data the client sends from here on will be encrypted using the agreed security parameters. At this point, both the client and the server have all the components necessary to generate the master secret and then derive cryptographic session keys.
Both sides verify that the handshake has proceeded as planned and that both have generated identical keys by sending a final encrypted Finished message indicating to each other that CipherSuite is activated.
Client — Finished
First, the client sends an encrypted Finished message to the server. This message is a cryptographic hash (message digest), of all previous handshake messages combined, followed by a special number identifying client role, the master secret and padding. This is encrypted with the newly generated session key and sent to the server.
Server — ChangeCipherSpec
Now the server sends a ChangeCipherSpec message back to the client to tell the client that all data after this message will be encrypted.
Server — Finished
ChangeCipherSpec message is followed by an encrypted Finished message from the server to the client. This is a cryptographic hash generated by server, of all components used during hanshake process along with a special number identifying server role.
The final step in the TLS handshake is for each party to decrypt and verify the Finished message that it received. Both parties perform a computation using the master-secret and a hash of the handshake messages as inputs. This gets compared to the value received in the Finished message. If the values match, handshake process will be considered as succeeded such that both parties can start data transfer over the established secure channel of communication. If there was a problem with the verification then a ‘HandshakeFailure’ message is sent and the session is terminated.
