TLS 1.3: RFC 8446 and the structural reform of web security

CyberScan

Vulnerability assessment and automated pentest. Continuous asset discovery, AI risk prioritisation, integrated NIS2 compliance manager.

Discover CyberScan →

Cyber Security

CISO-as-a-service consulting: posture, remediation roadmap, ongoing support.

Discover →

After four years of work

On 10 August 2018 the Internet Engineering Task Force published RFC 8446 — “The Transport Layer Security (TLS) Protocol Version 1.3”. The document is the result of over four years of work by the TLS Working Group led by Eric Rescorla (Mozilla), formally started in 2014 under the pressure of Snowden revelations and numerous TLS 1.0/1.1/1.2 vulnerabilities that emerged between 2011 and 2016 (BEAST, CRIME, BREACH, POODLE, FREAK, Logjam, DROWN, ROBOT).

TLS 1.3 is not a minor revision: it is a conceptual rewrite of the protocol, preserving backward compatibility at the record layer but substantially breaking the handshake and cipher layers.

Core goals

The WG pursued three explicit objectives:

1. Removal of legacy — eliminate every algorithm and mode with known vulnerabilities or history of issues
2. Forward secrecy always — each session must resist future compromise of server private keys
3. Latency reduction — faster handshake, possibility of 0-RTT to resume sessions

What has been removed

TLS 1.3 drastically cuts the cryptographic surface:

• Cipher block chaining (CBC) — vulnerable to padding oracles (BEAST, POODLE)
• Stream cipher RC4 — definitively broken from 2013
• 3DES — deprecated due to Sweet32 (2016)
• MD5 and SHA-1 — practical collisions demonstrated
• RSA key exchange (not signatures) — does not provide forward secrecy
• Static Diffie-Hellman — does not provide forward secrecy
• Weak DH parameters — vulnerable to Logjam
• Compression — vulnerable to CRIME
• Renegotiation — complex and source of bugs
• Custom padding algorithms — unified

The result is a protocol where “wrong choices” no longer exist: any combination allowed by the standard is cryptographically sound.

What has been added or changed

• 1-RTT handshake — one round-trip between client and server to establish the session, vs. two for TLS 1.2. The ClientHello already includes an ECDHE key share for a list of supported curves
• 0-RTT resumption — a client that has already spoken with the server can send application data immediately in the first packet, with specific risks (replay) the client must manage
• AEAD cipher only — AES-GCM, AES-CCM, ChaCha20-Poly1305. Encryption and authentication in a single primitive
• HKDF as standard key schedule
• Signature schemes separated from key exchange — clean separation
• Encrypted record contents — content type is encrypted, not exposed in TLS data
• Supported Groups — ECDHE with modern curves (X25519, X448, secp256r1/384/521)

Open source implementations

At the RFC’s publication (August 2018), many implementations already had experimental TLS 1.3 support based on drafts:

• OpenSSL 1.1.1 — release planned for September 2018, first LTS release with TLS 1.3
• BoringSSL (Google) — support from 2017
• NSS (Mozilla Firefox/Chrome) — support from Firefox 60 (May 2018)
• Rustls — Rust implementation, TLS 1.3-native
• wolfSSL, mbedTLS — embedded implementations with 1.3 support in preparation
• Go crypto/tls — support planned for Go 1.12 (February 2019)

Nginx, Apache HTTP Server, HAProxy gain TLS 1.3 support with the new OpenSSL versions.

2018-2020 adoption

In the months after the RFC:

• Browsers — Firefox, Chrome, Safari, Edge support TLS 1.3 by default by end 2018
• Cloudflare, Fastly, Akamai — enable TLS 1.3 on edge CDNs
• Google Search — serves TLS 1.3 by default
• Facebook — broad migration
• Banks, e-commerce — gradual, depending on compliance policy

Qualys SSL Labs updates to test TLS 1.3 configuration and indicate it in grading classes.

Browsers deprecate TLS 1.0/1.1

Parallel to the TLS 1.3 release, the main browsers (Microsoft, Google, Mozilla, Apple) announce in October 2018 the coordinated deprecation plan for TLS 1.0 and TLS 1.1 by March 2020. The joint announcement accelerates abandonment of old versions: many TLS-1.0-only servers are forced to upgrade.

Implications for products

For development teams and corporate CISOs:

• PCI-DSS compliance — versions 3.2 and later require TLS 1.2+ minimum
• FIPS 140-2/3 — updates to align governmental compliance
• NIS2 (2022) and GDPR — require “state of the art” encryption; TLS 1.3 fits
• AgID — indications on software security with TLS 1.2 minimum, 1.3 recommended
• TLS audits — tools like testssl.sh, sslyze, nmap --script ssl-enum-ciphers become pentest standard

Remaining limits

TLS 1.3 solves many issues but not all:

• Trust in Certificate Authorities — remains substantially unchanged; Certificate Transparency (RFC 6962) helps but does not replace it
• Encrypted SNI — the hostname in ClientHello is still transmitted in cleartext; ECH (Encrypted ClientHello) is in IETF development
• Post-quantum — TLS 1.3 does not include quantum-resistant algorithms; post-quantum standardisation work is under way (NIST competition, concluded with CRYSTALS-Kyber, CRYSTALS-Dilithium in 2022)

In the Italian context

As of 2018 Italian TLS 1.3 adoption is rapid for major players (banking portals, national PA, telco) and gradual for SMEs and local administrations. Initiatives improving public TLS posture — AgID portals, Italia Login (SPID/CIE), regional Electronic Health Record — progressively align to 1.2+ and then 1.3 during 2019-2021.

References: RFC 8446 — “The Transport Layer Security (TLS) Protocol Version 1.3” (IETF, 10 August 2018). TLS Working Group, chair Eric Rescorla. OpenSSL 1.1.1 (September 2018). Browser TLS 1.0/1.1 deprecation (October 2018 → March 2020). Qualys SSL Labs.