TLS 1.3 Explained: RFC 8446 + Handshake Walkthrough

Article 3 of 6: Understanding TLS Security Series

TLS 1.3, finalized in August 2018 (RFC 8446), is a fundamental redesign of the protocol. It removes decades of accumulated security debt while improving both performance and privacy.

This article covers the streamlined 1-RTT handshake, HKDF key derivation, removed legacy features, 0-RTT resumption, Encrypted Client Hello (ECH), and post-quantum key exchange.

Key findings

• TLS 1.3 (RFC 8446) was finalized in August 2018 as a fundamental redesign of the protocol. It is not an incremental upgrade over TLS 1.2; it removes decades of accumulated security debt while improving performance.
• 1-RTT handshake is the default for new connections. The client sends its ECDHE key share speculatively in the first message, allowing encryption to start after one round trip instead of two. 0-RTT resumption is available for returning clients but carries replay risk and should be restricted to idempotent requests.
• Forward secrecy is mandatory in TLS 1.3, always via ECDHE. Static RSA key exchange is removed, eliminating the “key compromise decrypts all past traffic” failure mode.
• The certificate is encrypted during the TLS 1.3 handshake. Passive network observers cannot see which certificate was presented, only the server IP and (without ECH) the SNI hostname in Client Hello.
• HKDF (HMAC-based Key Derivation Function, RFC 5869) replaced the TLS 1.2 PRF. HKDF is built on standard HMAC primitives, has been formally verified, and uses a three-stage key schedule (Early Secret, Handshake Secret, Master Secret) that prevents key reuse across derivation stages.
• Only 5 cipher suites exist in TLS 1.3, all AEAD. TLS_AES_256_GCM_SHA384, TLS_AES_128_GCM_SHA256, TLS_CHACHA20_POLY1305_SHA256, TLS_AES_128_CCM_SHA256, TLS_AES_128_CCM_8_SHA256. No weak options possible. Key exchange and authentication are negotiated separately via extensions, not embedded in the cipher suite name.
• Removed legacy features eliminate entire attack categories: RSA key exchange (no forward secrecy), CBC ciphers (POODLE, Lucky13, BEAST), RC4 (keystream biases), 3DES (Sweet32), MD5/SHA-1 signatures (SHAttered collision), compression (CRIME/BREACH), renegotiation, static DH/ECDH, and custom DH groups (Logjam).
• Encrypted Client Hello (ECH) hides SNI from passive observers by encrypting the entire Client Hello. Requires DNS-over-HTTPS (DoH) for full privacy. Enabled by default on Cloudflare, supported by Chrome (since 2023) and Firefox.
• Hybrid post-quantum key exchange (X25519MLKEM768 or X25519Kyber768) combines classical X25519 with ML-KEM, providing security against both classical and quantum attackers. Already deployed at Cloudflare and Google scale.

Cybersecify is a founder-led penetration testing firm based in Bengaluru, India, serving AI-first and API-first SaaS startups. We provide pentest and security consulting for SaaS startups, and we validate TLS configuration (including TLS 1.3 enforcement, forward secrecy, cipher suite hygiene, ECH support, and post-quantum readiness) during our Web Application Pentest and IoT Pentest engagements. See a redacted sample report for the structure of findings we deliver.

TLS 1.3 vs TLS 1.2 Comparison

Feature	TLS 1.2	TLS 1.3
Handshake RTT	2-RTT	1-RTT (0-RTT resume)
Forward Secrecy	Optional (ECDHE)	Mandatory
Certificate Privacy	Plaintext (visible)	Encrypted (hidden)
Cipher Suites	37+ (many weak)	5 (all AEAD)
Key Derivation	PRF	HKDF
RSA Key Exchange	Supported	Removed
CBC Ciphers	Supported	Removed

1. TLS 1.3 Handshake (1-RTT)

Theory: How It Works

The key innovation: the client sends its key share speculatively in the first message, allowing encryption after just one round trip.

CLIENT                                          SERVER
  |                                               |
  |  1. Client Hello + Key Share                  |
  |  ──────────────────────────────────────────►   |
  |  TLS 1.3, ciphers, ECDHE public key           |
  |                                               |
  |              2. Server Hello + Key Share       |
  |  ◄──────────────────────────────────────────   |
  |  Selected cipher, server ECDHE key             |
  |                                               |
  |  ═══════ ENCRYPTION STARTS ═══════            |
  |                                               |
  |              3. Encrypted Extensions           |
  |  ◄──────────────────────────────────────────   |
  |  Additional parameters (encrypted)             |
  |                                               |
  |              4. Certificate (ENCRYPTED!)       |
  |  ◄──────────────────────────────────────────   |
  |  Hidden from observers!                        |
  |                                               |
  |              5. Certificate Verify             |
  |  ◄──────────────────────────────────────────   |
  |  Signature over transcript                     |
  |                                               |
  |              6. Server Finished                |
  |  ◄──────────────────────────────────────────   |
  |  MAC over handshake                            |
  |                                               |
  |  7. Client Finished                           |
  |  ──────────────────────────────────────────►   |
  |  Handshake complete                            |
  |                                               |
  |  Application Data (Encrypted)                 |
  |  ◄────────────────────────────────────────►   |

              Total: 1 Round Trip (1-RTT), 50% Faster!

Key Differences from TLS 1.2:

• Certificate is ENCRYPTED, so observers cannot see the destination
• Key share sent speculatively, saving one round trip
• No Change Cipher Spec message, resulting in a cleaner protocol
• Encryption starts immediately after Server Hello

Practical: Real-World Implementation

# Force TLS 1.3
openssl s_client -connect example.com:443 -tls1_3

# Show TLS 1.3 cipher suites
openssl ciphers -v -tls1_3

# Verify TLS 1.3 support
openssl s_client -connect example.com:443 2>&1 | grep Protocol

Wireshark Visibility Comparison:

Packet	TLS 1.2	TLS 1.3
Client Hello	Visible	Visible
Server Hello	Visible	Visible
Certificate	VISIBLE	ENCRYPTED
Server Key Exchange	Visible	N/A
Application Data	Encrypted	Encrypted

Reality: Security Risks

Issue	Impact	Solution
SNI Visible	Server name in Client Hello plaintext	Encrypted Client Hello (ECH)
Middlebox Issues	Some firewalls break TLS 1.3	Middlebox compatibility mode
Legacy Clients	Old browsers lack support	Enable TLS 1.2 fallback

2. Key Derivation (HKDF)

Theory: How It Works

TLS 1.3 uses HKDF (HMAC-based Key Derivation Function) instead of PRF, providing cleaner cryptographic separation.

HKDF Key Schedule:

Stage 1 - Early Secret (0-RTT):
  Early Secret = HKDF-Extract(salt=0, PSK or 0)

Stage 2 - Handshake Secret:
  Handshake Secret = HKDF-Extract(derived, ECDHE_secret)

Stage 3 - Master Secret:
  Master Secret = HKDF-Extract(derived, 0)

Function	Purpose
HKDF-Extract	Combines salt + input key material into PRK
HKDF-Expand	Derives multiple keys from single secret
Derive-Secret	TLS 1.3 wrapper with transcript hash

HKDF in TLS 1.3 has been formally verified. The key schedule design prevents key reuse across derivation stages, eliminating entire classes of attacks.

3. 0-RTT Resumption

Theory: How It Works

0-RTT allows returning clients to send encrypted data in the first message, before the handshake completes.

How It Works:

1. First connection: Normal 1-RTT, server issues session ticket
2. Subsequent: Client sends ticket + early data in first message
3. Server decrypts early data using PSK from ticket

Practical: Real-World Implementation

Enable 0-RTT (Nginx):

ssl_early_data on;
proxy_set_header Early-Data $ssl_early_data;

Reality: Security Risks

Risk	Impact	Mitigation
Replay Attack	Attacker replays 0-RTT data	Only send idempotent requests (GET)
No Forward Secrecy	Early data encrypted with PSK only	Use single-use session tickets
Double Submit	Non-idempotent action runs twice	Server-side replay detection

4. Removed Legacy Features

TLS 1.3 removes all weak and problematic features from previous versions:

Removed Feature	Why Removed
RSA Key Exchange	No forward secrecy; key compromise decrypts all past traffic
CBC Cipher Suites	Padding oracle attacks (POODLE, Lucky13, BEAST)
RC4	Cryptographically broken, with biases in keystream
3DES	64-bit block vulnerable to Sweet32 birthday attack
MD5/SHA-1 signatures	Collision attacks (SHAttered)
Compression	CRIME/BREACH attacks leak secrets
Renegotiation	Complex, enabled various attacks
Static DH/ECDH	No forward secrecy
Custom DH groups	Weak groups (Logjam attack)

By removing these features, TLS 1.3 eliminates entire attack categories. There are no known practical attacks against properly implemented TLS 1.3.

5. TLS 1.3 Cipher Suites

TLS 1.3 has only 5 cipher suites, all AEAD, all secure. No configuration mistakes possible.

Cipher Suite	Recommendation
TLS_AES_256_GCM_SHA384	RECOMMENDED, highest security
TLS_AES_128_GCM_SHA256	RECOMMENDED, good balance
TLS_CHACHA20_POLY1305_SHA256	RECOMMENDED, fast on mobile
TLS_AES_128_CCM_SHA256	OK, constrained IoT devices
TLS_AES_128_CCM_8_SHA256	OK, very constrained devices

Key exchange (ECDHE) and authentication (RSA/ECDSA) are negotiated separately via extensions, not in the cipher suite name. All TLS 1.3 cipher suites are secure, so you cannot make a bad choice.

6. Encrypted Client Hello (ECH)

Theory: How It Works

ECH encrypts the entire Client Hello, including SNI (Server Name Indication). This hides which website you’re connecting to from network observers.

Privacy Comparison:

Metadata	TLS 1.3 (no ECH)	TLS 1.3 + ECH
Server IP	Visible	Visible
SNI (domain name)	Visible in Client Hello	ENCRYPTED
Certificate	Encrypted	Encrypted
Application Data	Encrypted	Encrypted

Practical: Real-World Implementation

# Check if server supports ECH
dig +short TYPE65 _https.example.com  # Look for 'ech=' parameter

# Enable ECH in Firefox (about:config)
# network.dns.echconfig.enabled = true

Reality: ECH Adoption 2026

Platform	ECH Status
Cloudflare	ECH enabled by default for all sites
Chrome	ECH supported since 2023
Firefox	ECH enabled by default

ECH requires DNS-over-HTTPS (DoH) for full privacy.

7. Post-Quantum Key Exchange

Theory: How It Works

TLS 1.3 now supports hybrid post-quantum key exchange. The client and server perform both X25519 (classical) and ML-KEM (post-quantum) key exchanges, combining the results. This provides security against both classical and quantum attackers.

# Check for hybrid PQ key exchange in connection
openssl s_client -connect cloudflare.com:443 2>&1 | grep 'Server Temp Key'
# Look for: X25519MLKEM768 or X25519Kyber768

8. Wireshark Packet Analysis

TLS 1.3 with Self-Signed Certificate

• Wireshark Filter: tls.handshake.type == 1 || tls.handshake.type == 2 || tls.record.content_type == 23
• Visible Packets: Client Hello, Server Hello, Application Data…
• Certificate Details: NOT VISIBLE. Certificate is encrypted inside Application Data packets
• Browser Behavior: Security warning shown (self-signed) but attacker cannot see which site

Key Observations:

• No Certificate packet visible after Server Hello
• Only “Application Data” packets (encrypted content)
• Expand Client Hello to see supported_versions with TLS 1.3 (0x0304)
• Passive observer cannot determine server identity from certificate

TLS 1.3 with CA-Issued Certificate

• Visible Packets: Client Hello, Server Hello, Application Data (encrypted)
• Certificate Details: NOT VISIBLE. Only SNI (server_name) in Client Hello reveals destination
• Browser Behavior: Padlock icon shown, fully trusted and private connection

9. Technical Comparison Matrix

Scenario	Cert Visible?	Trusted?	Speed	Security
TLS 1.2 + Self-Signed	Yes	No	Medium	Moderate
TLS 1.2 + CA Cert	Yes	Yes	Medium	High
TLS 1.3 + Self-Signed	No	No	Fast	High*
TLS 1.3 + CA Cert	No	Yes	Fastest	HIGHEST

*High encryption but no trust verification without CA certificate

Key Takeaways

• 1-RTT handshake (0-RTT for resumption), 50% faster
• Forward secrecy is mandatory, always ECDHE
• Certificate is encrypted, improving privacy
• Only 5 AEAD cipher suites with no weak options
• HKDF key derivation: cleaner and formally verified
• 0-RTT has replay risk, so use it carefully
• ECH hides SNI for complete privacy
• Hybrid PQ (X25519 + ML-KEM) for quantum resistance
• TLS 1.3 + CA certificate = HIGHEST security

---

Previous: Article 2: TLS 1.2 Deep Dive

Next: Article 4: TLS Attacks & Vulnerabilities

This is part of our 6-article series on Understanding TLS Security.

Related reading:

• TLS 1.2 Deep Dive for the legacy protocol you may still need to support
• TLS Attacks and Vulnerabilities for the historical attack catalogue that drove TLS 1.3’s design
• Sample Pentest Report for the structure of TLS findings we deliver

Not sure if your TLS 1.3 migration is complete? We validate TLS configuration during our Web Application Pentest and IoT Pentest engagements. Get a free security snapshot to check what’s exposed, or view pricing.