Demystifying the TLS Protocol: Evolution from 1.2 to 1.3

Demystifying the TLS Protocol: Evolution from 1.2 to 1.3 and Core Technologies In internet communications, the TCP protocol ensures reliable data transmission, while HTTP defines application-layer data formats. However, both lack a critical element: security. When data travels across untrusted networks, it faces three primary threats:

1. Eavesdropping: Sensitive information like passwords can be intercepted
2. Tampering: Transmission content may be maliciously modified (e.g., injecting ads into webpages)
3. Spoofing: Attackers may impersonate legitimate websites (e.g., fake banking pages)

The Transport Layer Security (TLS) protocol was designed to address these issues, providing three core security mechanisms:

• Encryption: Uses advanced cryptographic algorithms to ensure only communicating parties can decrypt content
• Integrity Verification: Prevents data tampering through message authentication
• Authentication: Validates server/client identities using digital certificates

Learning Tip: For an intuitive understanding of TLS, we recommend watching Why HTTPS is Secure before continuing. This article serves as a technical deep dive focusing on TLS 1.2 and 1.3 mechanisms and their differences.

This article will analyze:

• TLS 1.2's fundamental workings
• Key improvements in TLS 1.3
• Security and efficiency comparisons between both versions

TLS 1.2 uses a classic 2-RTT handshake protocol with this complete workflow:

Client                                                  Server

ClientHello                 -------->
                                                ServerHello
                                               Certificate*
                                         ServerKeyExchange*
                                        CertificateRequest*
                            <--------      ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished                    -------->
                                         [ChangeCipherSpec]
                            <--------             Finished
Application Data            <------->     Application Data

(* indicates optional messages depending on context)

Imagine you (Client) and a bank website (Server) as two agents establishing secure communication in hostile territory.

Objectives

• Confirm mutual authenticity (prevent MITM attacks)
• Negotiate "code phrases" (encryption algorithms)
• Generate unique session keys (Master Secret)

Step-by-Step Process

1. 🔵 Step 1: ClientHello - Client Launch Connection

   👉 You (Client) say to the server：

   Hello! I support these cipher suites (TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 etc.), here's my random number (Client Random), let's establish a secure session!

   Technical Details：

   • Parameters：
     • ✅ TLS version (e.g., 1.2)
     • ✅ Cipher suite list (e.g., ECDHE_RSA+AES_128_GCM)
     • ✅ Client Random (32-byte random number)
     • ✅ Session ID (for session resumption)
   • Cipher Suite Example：
     TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
     • Key Exchange: ECDHE (ephemeral keys for forward secrecy)
     • Authentication: RSA signatures
     • Symmetric Encryption: AES-128-GCM
     • Hash Algorithm: SHA-256

2. 🟢 Step 2: ServerHello - Server Negotiation Response

   👉 Bank Website replies

   Received! We'll use ECDHE_RSA+AES_128_GCM, here's my random number (Server Random), and my ID (certificate)!

   Key Actions：

   1. Selects optimal cipher suite from client's options
   2. Generates Server Random (32 bytes) for key derivation
   3. Includes session ID (for resumption)

3. 📜 Step 3: Certificate - Identity Authentication

   👉 Bank Website presents certificate

   This is an X.509 certificate issued by DigiCert, containing my public key and CA signature, please verify

   Verification Process：

   1. Validates certificate chain trust
   2. Checks certificate validity period and domain match
   3. Confirms certificate isn't revoked (OCSP/CRL checks)

4. 🔑 Step 4: ServerKeyExchange - Key Exchange Parameters

   （Required only for ephemeral key algorithms like ECDHE/DHE）
   👉 Bank Website adds：

   Here are elliptic curve parameters (secp256r1) and my ephemeral public key for key calculation

   Technical Points：

   • Includes signature to prevent parameter tampering
   • Ephemeral keys provide forward secrecy (PFS)

5. 🛡️ Step 5: CertificateRequest (Optional)

Upon completing these steps, the TLS handshake concludes:

✅ All communication now uses AES-128-GCM encryption
✅ Unique per-session keys ensure forward secrecy
✅ Browser displays 🔒 icon (HTTPS)

Imagine establishing a super-secure chat room requiring multiple keys:

• Key 1: Encrypt your messages
• Key 2: Encrypt friend's messages
• Key 3: Verify message integrity
• ...

TLS 1.2's key derivation acts as a key factory, using initial "raw material" (Pre-Master Secret) mixed with random numbers to "juice out" all required keys.

1. Stage 1: Create "Universal Base Key" (Master Secret)

   Starting with temporary pre_master_secret, process it into a more secure base:

   Formula:

   master_secret = PRF(
       input: pre_master_secret,
       label: "master secret",
       seasoning: client_random + server_random
   )

   • "Juicer": TLS 1.2's PRF (pseudorandom function), essentially a mathematical blender (HMAC-SHA256 based).
   • "Seasoning": Client/server random numbers exchanged during handshake ensure unique session keys.

   Purpose: This master_secret acts as the "mother key" for deriving subsequent keys but isn't directly used for encryption.

2. Stage 2: Mass-Produce "Session Key Bundle" (Key Block)

   Using the base key to generate practical encryption keys:

   Formula:

       input: master_secret,
       label: "key expansion",
       seasoning: server_random + client_random (reversed!)
   )

Key Takeaways

1. Layered Derivation: pre_master_secret → master_secret → key_block.
2. Randomness Assurance: Client/server randoms ensure unique session keys.
3. Precise Allocation: Specialized keys for specific tasks like factory assembly.

The TLS record layer functions like a secure packaging workshop, preparing data (e.g., web content, passwords) for encrypted network transmission in two phases:

1. Phase 1: Plaintext (Pre-Packaging)

   Original data (e.g., "hello") is structured as:

   struct {
       ContentType type;       // Label: package type?
                               // 20: Key change notice
                               // 21: Alert
                               // 22: Handshake
                               // 23: User data
       ...