What is a TLS handshake?
TLS is an encryption protocol designed to secure Internet communications. A TLS handshake is the process that kicks off a communication session that uses TLS encryption. During a TLS handshake, the two communicating sides exchange messages to acknowledge each other, verify each other, establish the encryption algorithms they will use, and agree on session keys. TLS handshakes are a foundational part of how HTTPS works.
SSL, or Secure Sockets Layer, was the original encryption protocol developed for HTTP. SSL was replaced by TLS, Transport Layer Security, some time ago. SSL handshakes are now called TLS handshakes, although the "SSL" name is still in wide use.
When does a TLS handshake occur?
A TLS handshake takes place whenever a user navigates to a website over HTTPS and the browser first begins to query the website's origin server.
A TLS handshake also happens whenever any other communications use HTTPS, including API calls and DNS over HTTPS queries.
TLS handshakes occur after a TCP connection has been opened via a TCP handshake.
How Does it Occur?
When establishing a secure session, the Handshake Protocol manages the following:
- Cipher suite negotiation
- Authentication of the server and optionally, the client
- Session key information exchange.
In Cipher Suite Negotiation, the client and server make contact and choose the cipher suite that will be used throughout their message exchange. This means, that the client (Browser) which wants to establish secure communication between the client and the server, sends the cipher suits it supports (AES_128, SHA256) and the compatible SSL/TLS version such as TLS (TLS 1.0, 1.2, 1.3 etc.) to server. This is Client Hello message
Then the Server replies to the client that it is compatible with the cipher suites and the TLS version of the client. The server will also send back the cipher suite it selects from the list of ciphers presented by the client. This is also called as Server Hello Message.
The server will also send the certificate of the server with the certificate chain. The certificate chain will be validated against the certificates in the client trust store. The certificate chain is shown below.
** Certificate chain
chain [0] = [
[
Version: V3
Subject: CN=server, OU=ID, O=IBM, L=Hursley, ST=Hants, C=GB
Signature Algorithm: SHA256withRSA, OID = 1.2.840.113549.1.1.11
Key: Sun RSA public key, 2048 bits
modulus: 17397562757879783124811507432494159361243533796048391161052829821122241422546147907779583980536886743765496985274573369668302996974964349098220930856827026983442125212118340479175872257401994146576001849503528844021528618702289642320157895787705650513758990004411195572445830613057931701313142946380207623174021376881040589912594451781207558263630010509870784494298596448861811827669869221033031956053367890915692918086795954628465637743034777850129818069833958463245749899713073673871721233098662285260745282530972322499603703844901496085490388703767606182211892402117158287170480970610942364235511256363933850852797
public exponent: 65537
Validity: [From: Tue 10 09:08:48 IST 2019,
To: Sun Tue 10 09:08:48 IST 2020]
Issuer: CN=server, OU=ID, O=IBM, L=Hursley, ST=Hants, C=GB
SerialNumber: [ 7d834874]
Certificate Extensions: 1
[1]: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: C7 24 EA C3 1E 3E 58 8E BD E3 AE A9 17 01 00 51 .$…>X……..Q
0010: B0 83 D4 68 …h
]
]
]
Algorithm: [SHA256withRSA]
Signature:
0000: 4B FA 93 D8 56 78 05 D8 89 BC 2A 3A B6 C3 7F A5 K…Vx….*:….
0010: 03 D8 56 3B E6 9F 0B 17 B5 A2 61 AE 43 46 A4 85 ..V;……a.CF..
0020: 3F 60 2E 04 41 0D C2 7A 35 0D 56 F5 FE 9D 05 51 ?`..A..z5.V….Q
0030: 4A 0B BB 5B 30 ED 85 AF 1C 95 13 15 7D A0 2C DE J..[0………,.
0040: B4 A1 7A D0 5D E4 C0 91 37 C2 ED 37 39 65 7D 02 ..z.]…7..79e..
0050: B5 A4 72 FF EB 6C D5 F4 FD BC 32 FD 9F C8 3A 49 ..r..l….2…:I
0060: 53 64 F8 C6 A0 D6 DB 89 2C 36 60 97 8B 33 8F 95 Sd……,6`..3..
0070: 18 9C 1A F2 F8 F1 66 5E F3 0B 76 54 08 AB A9 88 ……f^..vT….
0080: 5D E9 2D 6B AE 6D 98 09 57 A0 2A 9E C6 6B 89 53 ].-k.m..W.*..k.S
0090: 8E B3 58 C3 8D 73 C5 D3 58 2F 68 F0 4E 0A EF 29 ..X..s..X/h.N..)
00A0: 54 95 00 34 6A C4 D2 56 22 64 05 F9 9F A4 81 44 T..4j..V"d…..D
00B0: 44 77 95 A7 86 5A D3 EE EA 8E 06 19 ED 94 F1 83 Dw…Z……….
In the next step, the server key exchange message is sent to the client. This message carries the required details for the client to generate the per-master secret. This message is sent only if the client requires the information from the server to generate a pre-master secret. Such as Elliptic Curve Diffie Hellman (ECDH) Algorithm.
There are two types of Handshakes mainly in SSL: one way and two way. In Two way, the server will send a certificate request from the client with the certificate type, certificate signature algorithms and certificate authorities supported by the server. In one-way SSL handshake, the authenticity of the client will not be validated, so that the certificate request will not be sent by the server.
The Server Hello message ends here and the server will wait for the client response.
The Client will reply to the server with its own certificate chain. Then it sends Client Key Exchange Message to the server. In order to maintain the encrypted transmission of the data between the server and the client in an HTTPS connection, they will use either symmetric or asymmetric encryption.
Symmetric encryption will be used more often, as the computational cost is much lower than Asymmetric encryption. In order to use symmetric encryption, there needs to be a common key between the two ends. The purpose of this message is to generate that common key between that client and the server without exposing to an outsider.
There are two client key exchange methods described in the TLS v1.2 spec. They are RSA and Diffie-Hellman.
If RSA is used as the key exchange algorithm, the client generates a 48-byte pre-master secret. The client encrypts the pre-master secret by the public key of the certificate and sends to the server. Only the server will have the corresponding private key to decrypt and get the client generated pre-master secret.
If Diffie-Hellman is used, the Diffie-Hellman parameters are transmitted to allow both client and server to generate the same pre-master secret.
After that, both sides will generate a master secret using the pre-master secret and the master secret will be used to generate the symmetric key for encrypting the session data.
A change cipher spec message will be sent by both client and server indicating that the rest of the communication will be encrypted only after successful authentication and generating the pre-master secrets/master secrets.
Then a Final message is sent, this will be the first message encrypted with the negotiated algorithms. Application data will be transferred only after both parties send the finished message and verifying the content of the message.
