You probably know that your HTTP requests will likely use TLS (Transport Layer Security) to create an encrypted connection, but most developers don’t know what happens in a client-server connection when it’s encrypted using TLS. This article will explain a TLS handshake to give developers a better understanding of how their applications work under the hood.
Note: SSL and TLS are terms often used interchangeably, but TLS is the upgraded new version of SSL. SSL versions 2 and 3 are no longer cryptographically secure. SSL 3.1 was named TLS, and TLS has also gone through several versions. Although SSL and TLS are used interchangeably, I”ll refer to it as TLS.
Which TLS Version is Secure?
It’s not enough to simply say that your application is secure because it uses TLS. The version of TLS that you use matters, but there is a catch to requiring strong protocols and ciphers – your users must support the version that you use. Clients use the TLS handshake to determine the protocol and cipher to use for communication, and both client and server must support them.
TLS is a protocol, and ciphers are the algorithms used to encrypt communications. TLS protocol versions support different ciphers. TLS 1.3 supports much fewer ciphers, but it’s a more streamlined handshake with fewer pitfalls and error capabilities.
You should also consider compliance when you choose a TLS version. Older TLS version 1.0 should not be used, and 1.0 is explicitly forbidden in PCI-DSS requirements. If you take credit card payments in the application, chances are that you must follow PCI requirements. TLS 1.3 is the suggested protocol to use, but you might need to support TLS 1.2 for older browsers and devices.
- TLS 1.0: In no way should you allow this version.
- TLS 1.2: Allow only if necessary.
- TLS 1.3: Currently, this version is the most secure and recommended.
Performing a TLS Handshake
The following diagram is a simple visual representation of how the TLS 1.3 handshake (and other versions) work. Below is an explanation of each TLS handshake step.
1. Client Hello
This is the initial message sent from the client to an application server. Important data is sent with this initial message including:
- The protocol version the client supports.
- The session ID if there is already a session created.
- A list of cipher suites supported.
The TLS version you choose will determine cipher support. TLS 1.3 supports only 5 ciphers while TLS 1.2 supports 37. When the client sends a “hello” message, it sends the ciphers it supports. The server and the client must agree on the same cipher to communicate, but the server will choose the most secure cipher from the client list.
The following ciphers are supported in TLS 1.3:
- TLS_AES_256_GCM_SHA384
- TLS_CHACHA20_POLY1305_SHA256
- TLS_AES_128_GCM_SHA256
- TLS_AES_128_CCM_8_SHA256
- TLS_AES_128_CCM_SHA256
The following ciphers are supported in TLS 1.2:
- TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
- TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
- TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
- TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
- TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
- TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
- TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
- TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
- TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
- TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
- TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
- TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
- TLS_DHE_RSA_WITH_AES_128_CBC_SHA
- TLS_DHE_RSA_WITH_AES_256_CBC_SHA
- TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
- TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
Using the first TLS 1.3 cipher, you can get information from the name.
TLS_AES_256_GCM_SHA384
From the above cipher value, you get:
- TLS is the protocol
- AES_256_GCM is the Authenticated Encryption and Associated Data (AEAD) algorithm
- SHA384 is the Hashed-kEy Derivation Function (HKFD) algorithm
In the above example, AES-256 is what the application will use to encrypt data. Although encryption and decryption are invisible to the user, it might be important for a developer to know the encryption cipher used to validate that it’s cryptographically secure, especially if you’re communicating with a server with sensitive data.
If a session was already created, the Client Hello message also sends the existing session ID so that key exchange does not need to happen again. In an initial session, this value is not available so it’s set to 00.
2. Server Hello
To acknowledge the client, the server sends back a “hello” message as well. The server verifies that it supports the client’s TLS version and chooses the most secure cipher from the client’s supported ciphers.
3. Server Certificate
TLS handshake and communication use both asymmetric and symmetric keys. Asymmetric keys involve a public and private key. The public key is published to everyone, and anyone can use it to encrypt and send information to a person with the private key. Only the owner of the private key can decrypt the message, and in this case the server holds the private key. You install public-private key capabilities with the certificate that you install when you order an SSL/TLS certificate from a Certificate Authority (CA). Certificates offer HTTPS to client browsers, but it’s also a factor in the TLS handshake.
In this step of the handshake, the server sends the public key to the client along with information verifying that the certificate belongs to the host (e.g., the domain name in the user’s browser). If it does not validate, a standard browser will send an alert to the user telling them that the site could be a phishing site or dangerous.
4. Server Hello Done
A small message is sent to the client to indicate that the server is done with its half of the handshake.
5. Client Key Exchange Message and 6. Key Generation
At this point, the client must create a symmetric key and pass it to the server. The symmetric key is used by both the client and the server to decrypt and decrypt information. The client creates it, but you need a way to securely send it to the server. If you send the symmetric key to the server without encryption, it’s vulnerable to eavesdroppers because data isn’t encrypted yet. With the symmetric key, an attacker could decrypt messages between client and server, so this key must be transferred to the server safely.
We need a way to pass the symmetric key to the server. To ensure privacy of the symmetric key, asymmetric encryption is used. In step 2, the server sent certificate and public key information to the client. We have the public key for the server, so the client encrypts the symmetric key using the server’s public key, usually using the RSA protocol, but Diffie-Hellman can also be used. The symmetric key, encrypted with the server’s public key, is then passed to the server where it’s decrypted using the server’s private key. Now, the server and the client have the symmetric key, and communication can now take place securely using encryption.
7. Cipher Spec Exchange
This step only occurs with TLS 1.2. This step tells both client and server that a key was created and now any future communication will be encrypted. In TLS 1.3, this is inferred and has been eliminated.
Application Data
After the handshake, the TLS 1.3 handshake explained completes and the symmetric key will be used to encrypt all data transferred from the client to the server and back again.
How to Check TLS Version of a Website or Server
The easiest way to check TLS versions configured on a server including cipher suites supported is to use online tools. Here are a couple online tools that will check for you:
