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)

   （Used for mutual authentication, e.g., corporate banking）
   👉 Bank Website requests:

   Please present your client certificate

6. ✅ Step 6: ServerHelloDone

   👉 Bank Website concludes:

   My information is complete, awaiting your response

7. 🔐 Step 7: ClientKeyExchange - Key Generation

   👉 You (Client) begin key calculation:

   1. Generate 46-byte PreMasterSecret
   2. Encrypt with server's public key (RSA key exchange)
   3. Or send client ephemeral public key (ECDHE)

   Key Derivation Magic:

   MasterSecret = PRF(PreMasterSecret, "master secret", ClientRandom + ServerRandom)

8. 📝 Step 8: CertificateVerify (Optional)

   (When client authentication is required)
   👉 You provide proof:

   Here's my certificate signature proving I hold the private key

9. 🔄 Step 9: ChangeCipherSpec

   👉 Both parties declare:

   All subsequent communication will use negotiated encryption

10. 🔏 Step 10: Finished - Final Verification

    👉 Parties exchange encrypted verification messages:

    The eagle has landed! ↔ The bear sleeps in winter

    Security Significance:

    • Verifies handshake integrity
    • Confirms encrypted channel establishment

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:

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

   • Reversed seasoning order prevents hacker prediction.
   • The key_block is a long random string divided into specific segments.

3. Stage 3: Allocate Key Segments

   Dividing key_block into functional components:

   Key Segment	Purpose
   Client MAC Key	Verify your message integrity
   Server MAC Key	Verify server message integrity
   Client Encryption Key	Encrypt your data (e.g., AES key)
   Server Encryption Key	Encrypt server data
   Client IV (if needed)	For algorithms like AES-CBC
   Server IV (if needed)	Same as above

   Why Multiple Keys?

   • Security Isolation: Compromising one key doesn't affect others.
   • Bidirectional Independence: Separate keys for client/server prevent interference.

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
       ProtocolVersion version; // TLS version (e.g., 1.2)
       uint16 length;          // Package length (prevents truncation)
       opaque fragment[...];   // Raw data
   } TLSPlaintext;

   Real-World Analogy:

   Mailing a love letter (application_data):

   • Label envelope: "Love Letter-23" (type=23)
   • Specify: "2023 Secure Mail Standard" (version=TLS 1.2)
   • Weigh: "500g" (length=500)
   • Fold letter into envelope (fragment)

2. Phase 2: Encryption (Post-Packaging)

   Data is encrypted and compressed:

   struct {
       opaque content[...];    // Encrypted data
       ContentType type;       // Retains original label (now encrypted)
       ProtocolVersion version;
       uint16 length;          // New encrypted length
   } TLSCiphertext;

   Critical Changes:

   1. Content Encryption: Letter becomes ciphertext ("I love you"→"X7$kP")
   2. Intact Metadata: Labels remain visible for routing but content is locked
   3. Tamper Proofing: Encryption includes MAC; modifications are detectable

Design Rationale

1. Type Separation:
   • Handshake (22) and user data (23) follow different paths
   • Alerts (21) can trigger immediate actions (e.g., attack detection)
2. Length Enforcement:
   • Prevents truncation or data injection
3. Version Control:
   • Supports backward compatibility (e.g., TLS 1.2 devices connecting to 1.3 servers)

Security Highlights

• Transparent Metadata: Encrypted content but visible type enables proper routing.
• Size Accuracy: Encrypted length matches actual data to prevent padding attacks.
• Version Fallback: version field allows downgrade (though modern systems disable insecure versions).

This design makes the TLS record layer a bulletproof conveyor belt, efficiently categorizing and securing data packages. 🚚🔒

Despite TLS 1.2's robust design, practical implementations reveal vulnerabilities:

(Note: TLS 1.3 comprehensively addresses these issues)

TLS 1.3 (RFC 8446), published in 2018, represents a major protocol overhaul addressing TLS 1.2's shortcomings.

1. Faster 1-RTT Handshake (0-RTT optional)
2. Removed Insecure Algorithms: Eliminated RC4, DES, 3DES, AES-CBC, SHA1, MD5
3. Mandatory Forward Secrecy: All public-key exchanges use ephemeral keys
4. Simpler Cipher Suites: No separate negotiation of auth/encryption/MAC algorithms
5. Encrypted Handshake: All messages except Hello's are encrypted

Standard 1-RTT Handshake:

Client                                               Server
  │
  │ 1. ClientHello (with key material)
  │    - key_share* (ephemeral public key)
  │    - signature_algorithms* (supported schemes)
  │    - pre_shared_key* (for session resumption)
  │  ----------------------------------------->
  │                                               │
  │                                               │ 2. ServerHello (selected cipher)
  │                                               │    - key_share* (server ephemeral key)
  │                                               │    - pre_shared_key* (resumption confirm)
  │                                               │
  │                                               │ 3. {EncryptedExtensions} (extra params)
  │                                               │ 4. {Certificate*} (server cert)
  │                                               │ 5. {CertificateVerify*} (authenticity proof)
  │                                               │ 6. {Finished} (handshake confirmation)
  │  <------------------------------------------
  │
  │ 7. {Certificate*} (client auth if required)
  │ 8. {CertificateVerify*} (client signature)
  │ 9. {Finished} (final confirmation)
  │  ----------------------------------------->
  │
  │ 10. [Application Data] (encrypted data flow)
  │  <---------------------------------------->

Critical Enhancements:

1. Client Key Sharing (key_share)

   • TLS 1.2: Client waits for server's cipher selection before sending ephemeral key (ClientKeyExchange).
   • TLS 1.3: Client includes ephemeral public key in initial ClientHello, allowing immediate key computation.

   Impact: Handshake reduced from 2-RTT to 1-RTT, accelerating page loads.

2. Safer Key Derivation (HKDF)

   • TLS 1.2: Uses PRF with complex structure.
   • TLS 1.3: Employs HKDF (HMAC-based Extract-and-Expand Key Derivation Function) for clearer key hierarchy.

   Key Hierarchy Example:

   Master Secret  
      ├── Handshake Traffic Secret  
      ├── Application Traffic Secret  
      └── 0-RTT Key (if enabled)

   Compromising one key doesn't affect others.

3. Flexible Certificate Verification (signature_algorithms)

   • TLS 1.2: Defaults to RSA signatures, potentially insecure.
   • TLS 1.3: Client specifies supported signature algorithms (e.g., RSA-PSS, ECDSA), forcing servers to use secure options.

   Benefit: Avoids weak algorithms like RSA-PKCS#1 v1.5.

4. 0-RTT Session Resumption (pre_shared_key)

   • TLS 1.2: Session resumption requires full handshake (1-RTT).
   • TLS 1.3: Clients with prior connections can include pre_shared_key (PSK) for immediate 0-RTT data transmission.

   ⚠️ Caution: 0-RTT data is vulnerable to replay attacks (suitable only for non-sensitive operations like loading static resources).

TLS 1.3 uses HKDF for key derivation:

Early Secret (PSK or 0)
                   |
                   v
             Derive-Secret(., "derived", "")
                   |
                   v
(EC)DHE -> HKDF-Extract = Master Secret
                   |
                   +-----> Derive-Secret(., "c e traffic", ClientHello...)
                   |                         = Client write key
                   +-----> Derive-Secret(., "s e traffic", ClientHello...)
                   |                         = Server write key
                   +-----> Derive-Secret(., "exp master", ClientHello...)
                   |                         = Exporter key
                   v
            Derive-Secret(., "res master", ClientHello...)
                                         = Resumption master secret

TLS 1.3 permits 0-RTT under specific conditions, allowing clients to send application data immediately:

Client                                              Server

ClientHello
+ early_data
+ pre_shared_key
+ key_share
+ psk_key_exchange_modes
+ early_data_indication
(Application Data*)     -------->
                                                  ServerHello
                                                 + pre_shared_key
                                                 + key_share
                                        {EncryptedExtensions}
                                                   {Finished}
                        <--------       [Application Data*]
{Finished}              -------->
[Application Data]      <------->       [Application Data]

0-RTT Security Constraints:

• Limited to idempotent operations (e.g., GET requests)
• Vulnerable to replay attacks (server-side protections required)
• No forward secrecy

TLS 1.3's record layer removes compression and MAC, standardizing AEAD encryption (e.g., AES-GCM):

struct {
    opaque content[length];
    ContentType type;
    uint8 zeros[length_of_padding];
} TLSInnerPlaintext;

struct {
    ContentType opaque_type = 23; // application_data
    ProtocolVersion legacy_record_version = 0x0303; // TLS 1.2
    uint16 length;
    opaque encrypted_record[length];
} TLSCiphertext;

1. Prioritize TLS 1.3: Unless legacy compatibility is required
2. Cipher Suite Selection:
   • TLS 1.3 priority: AES-256-GCM > ChaCha20 > AES-128-GCM
   • TLS 1.2 priority: ECDHE+AES-GCM > ECDHE+ChaCha20
3. Certificate Selection:
   • Prefer ECDSA certificates (more efficient than RSA)
   • Ensure complete certificate chains
4. OCSP Stapling: Reduce certificate validation latency
5. HSTS: Enforce HTTPS via HTTP headers
6. Disable TLS 1.0/1.1: These versions are proven insecure

TLS 1.3's streamlined design, mandatory forward secrecy, and performance optimizations represent the future of secure protocols. With quantum computing advancements, we may see TLS extensions incorporating post-quantum cryptography (e.g., NIST-selected Kyber algorithm). Regardless, understanding TLS remains essential for building secure networked applications.

This article has equipped you with core TLS 1.2 and 1.3 mechanisms, security features, and performance characteristics. For production deployments, regularly update server configurations against emerging threats and validate setups using tools like Qualys SSL Test.

1. RFC 5246 - TLS 1.2
2. RFC 8446 - TLS 1.3
3. RFC 6066 - TLS Extensions
4. "Bulletproof SSL and TLS" - Ivan Ristić
5. Cloudflare TLS 1.3 Guide