TLS Protocol Explained: From Handshake to Encrypted Transmission
Design Goals of the TLS Protocol
Build a secure transport layer (Transport Layer Security) on top of a connection-oriented transport layer (such as TCP), providing cryptographic security, including:
Confidentiality: information is encrypted in transit and cannot be eavesdropped on
Integrity: if information is tampered with, both communicating parties can detect it
Authentication: both communicating parties are protected against identity impersonation
History of TLS
1995: SSL 2.0, proposed by Netscape, had design flaws and was quickly abandoned.
1996: SSL 3.0, began to gain popularity. In 2015 it was proven insecure and has been disabled.
1999: TLS 1.0, the Internet standards organization ISOC took over from Netscape and released TLS 1.0, an upgraded version of SSL.
2006: TLS 1.1, fixed some vulnerabilities.
2008: TLS 1.2, improved security, and in 2011 it no longer remained compatible with SSL.
2018: TLS 1.3, supports 0-rtt, greatly improves security, and removes encryption methods other than aead.
When people generally say ssl, they mean TLS, and today they usually mean version 1.2.
Concepts Related to Cryptographic Algorithms
Cryptographic communication protocols are also constructed in layers, roughly divided into four layers:
The bottom layer: implementations of basic cryptographic primitives, such as aes, rsa, md5, sha256, ecdh…
The second layer: algorithms that meet cryptographic standards once parameters are configured, including block ciphers, stream ciphers, signature algorithms, asymmetric encryption algorithms, MAC algorithms, etc., such as aes-128-cbc-pkcs7.
The third layer: semi-finished components built by combining multiple standard algorithms, such as symmetric encryption transport components (aes-128-cbc + hmac-sha256), authenticated key agreement algorithms (rsassa-OAEP + ecdh-secp256r1), digital envelopes (rsaes-oaep + aes-cbc-128 + hmac-sha256), key derivation algorithms (PRF - sha256)…
The top layer: finished cryptographic protocols/software assembled from various components, such as the TLS protocol, SSH protocol, iMessage protocol, Bitcoin protocol…
From the layered perspective above, TLS is roughly assembled from three components: a symmetric encryption transport component, an authenticated key agreement component, and a key derivation component.
These components can be broken down into five categories of algorithms. In TLS, these five categories combined are called a CipherSuite: authentication algorithms, encryption algorithms, message authentication code (MAC) algorithms, key exchange algorithms, and key derivation algorithms.
TLS Protocol Layering
TLS is primarily used to encrypt data transmission. Its core is a symmetric encryption transport component, and to generate the shared key for both communicating parties, an authenticated key agreement component is needed. Therefore, the TLS protocol has two main parts:
- The record protocol handles symmetric encryption.
- The handshake protocol handles authenticated key agreement.
There are also three auxiliary protocols:
- The changecipher spec protocol tells the peer to switch from handshake to record.
- The alert protocol communicates various return codes.
- The application data protocol passes application-layer data streams such as HTTP into the record layer for processing and transmission.
This ” authenticated key agreement + symmetric encryption transport” structure is common to most encrypted communication protocols.
record protocol
The record protocol handles symmetric encryption of application data and accounts for most of the traffic in a TLS connection.
The main process has 4 steps: data fragmentation, data compression, encryption and integrity protection, and adding the message header.
handshake protocol
The main role of the handshake protocol is to produce SecurityParameters and provide them to the record protocol. The biggest change TLS 1.3 makes relative to TLS 1.2 is in the handshake protocol. The overall TLS 1.2 handshake flow:
- The client and server negotiate the TLS protocol version and a Cipher Suite.
- Authenticate the peer’s identity (in HTTPS this is usually the client authenticating the server’s identity).
- Use a key agreement algorithm to generate a shared master secret.
The handshake flow is as follows:
Client Server
ClientHello -------->
ServerHello
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
Application Data <-------> Application Data
//*表示可选的消息，或根据上下文在某些情况下会发送的消息Main actions during the handshake:
- Exchange Hello messages to negotiate algorithms and exchange random values, etc.;
- Exchange the necessary cryptographic parameters so the client and server can negotiate the premaster secret;
- Exchange certificates and cryptographic parameters so the client and server can authenticate each other;
- Generate a shared master secret from the premaster secret and the exchanged random values;
- Provide the SecurityParameters to the record layer;
- The client and server confirm that both sides derived the same SecurityParameters and that the handshake data was not tampered with.
TLS 1.2 requires two data round trips (2-RTT) to complete the handshake.
Key changes in TLS 1.3
Faster speed
TLS 1.3 full handshake flow:
Client Server
ClientHello
+ key_share -------->
ServerHello
+ key_share
{EncryptedExtensions}
{CertificateRequest*}
{Certificate*}
{CertificateVerify*}
{Finished}
<-------- [Application Data*]
{Certificate*}
{CertificateVerify*}
{Finished} -------->
<-------- [NewSessionTicket]
[Application Data] <-------> [Application Data]It is mainly divided into 3 phases
- Key exchange: establish shared key material and select cipher parameters (all data after this phase is encrypted)
- Server parameters: establish other handshake parameters (whether the client is authenticated, application-layer protocol support, etc.)
- Authentication: authenticate the server (and optionally authenticate the client), provide key confirmation and handshake integrity verification
As you can see, TLS 1.3 completes the handshake in just one round trip (1-RTT), cutting the handshake time in half compared to TLS 1.2. For mobile website access, this can improve access efficiency by nearly 100ms.
Implementation approach: drop the various algorithm support from TLS 1.2, keep only a small set of negotiation algorithms, and use caching to fold key-exchange negotiation into the first RTT, reducing the entire interaction to 1-RTT.
Stronger security
For compatibility, TLS 1.2 retained support for many encryption algorithms and components from the SSL 2.0/3.0 era, making TLS 1.2 highly configurable. This also means that many people unfamiliar with TLS 1.2 end up configuring vulnerable sites.
Building on 1.2, TLS 1.3 removes insecure encryption algorithms, such as:
- RSA key transport: does not support forward secrecy
- CBC-mode ciphers: proven to have vulnerabilities and are susceptible to attacks
- RC4 stream cipher: unsafe for use in HTTPS
- SHA-1 hash function: SHA-2 is recommended
- Various custom DH components: proven vulnerable and susceptible to attacks
Summary
The TLS protocol is the core of secure HTTPS communication:
- TLS 1.2: Currently the widely used version; security depends on configuration
- TLS 1.3: More secure and faster; recommended
- 1-RTT handshake: TLS 1.3 significantly reduces connection latency
- Forward secrecy: Protects past communications from future key compromise
In practice, prioritize TLS 1.3, configure cipher suites properly, and let professional tools handle the complex security configuration for you.