TLS 1.3: RFC 8446 e la riforma strutturale della sicurezza web

CyberScan

Vulnerability assessment e pentest automatizzato. Asset discovery continuo, AI risk prioritization, NIS2 compliance manager integrato.

Scopri CyberScan →

Cyber Security

Consulenza CISO-as-a-service: postura, roadmap di remediation, supporto continuativo.

Scopri →

Dopo quattro anni di lavoro

Il 10 agosto 2018 l’Internet Engineering Task Force ha pubblicato RFC 8446 — “The Transport Layer Security (TLS) Protocol Version 1.3”. Il documento è il risultato di oltre quattro anni di lavoro del TLS Working Group guidato da Eric Rescorla (Mozilla), partito formalmente nel 2014 sotto la spinta delle rivelazioni Snowden e di numerose vulnerabilità di TLS 1.0/1.1/1.2 emerse tra il 2011 e il 2016 (BEAST, CRIME, BREACH, POODLE, FREAK, Logjam, DROWN, ROBOT).

TLS 1.3 non è una revisione minore: è una riscrittura concettuale del protocollo, con conservazione della backward compatibility sul piano del record layer ma rottura sostanziale sul piano dell’handshake e dei cipher.

Obiettivi centrali

Il WG ha perseguito tre obiettivi espliciti:

1. Rimozione del legacy — eliminare ogni algoritmo e modalità con vulnerabilità note o storia di problemi
2. Forward secrecy sempre — ogni sessione deve resistere a compromissione futura delle chiavi private del server
3. Latency riduzione — handshake più veloce, possibilità di 0-RTT per riprendere sessioni

Cosa è stato rimosso

TLS 1.3 elimina drasticamente la surface crittografica:

• Cipher block chaining (CBC) — vulnerabile a padding oracle (BEAST, POODLE)
• Stream cipher RC4 — rotto definitivamente dal 2013
• 3DES — deprecato per Sweet32 (2016)
• MD5 e SHA-1 — collisioni pratiche dimostrate
• RSA key exchange (non firme) — non fornisce forward secrecy
• Static Diffie-Hellman — non fornisce forward secrecy
• Weak DH parameters — vulnerabili a Logjam
• Compression — vulnerabile a CRIME
• Rinegotiation — complessa e fonte di bug
• Algoritmi di padding personalizzati — unificati

Il risultato è un protocollo dove non esistono più “scelte sbagliate”: qualunque combinazione permessa dallo standard è cryptographically sound.

Cosa è stato aggiunto o modificato

• Handshake 1-RTT — una sola round-trip tra client e server per stabilire la sessione, rispetto a due di TLS 1.2. Il ClientHello include già il key share ECDHE per un elenco di curve supportate
• 0-RTT resumption — un client che ha già parlato con il server può inviare dati applicativi immediatamente al primo pacchetto, con rischi specifici (replay) che il client deve gestire
• AEAD cipher only — AES-GCM, AES-CCM, ChaCha20-Poly1305. Cifratura e autenticazione in un’unica primitiva
• HKDF come key schedule standard
• Signature scheme separati dai key exchange — clean separation
• Encrypted record contents — il tipo di contenuto è cifrato, non esposto nei dati TLS
• Supported Groups — ECDHE con curve moderne (X25519, X448, secp256r1/384/521)

Le implementazioni open source

Al momento della pubblicazione dell’RFC (agosto 2018), molte implementazioni avevano già supporto TLS 1.3 sperimentale basato sui draft:

• OpenSSL 1.1.1 — rilascio previsto per settembre 2018, primo rilascio LTS con TLS 1.3
• BoringSSL (Google) — supporto da 2017
• NSS (Mozilla Firefox/Chrome) — supporto da Firefox 60 (maggio 2018)
• Rustls — implementazione Rust, TLS 1.3-native
• wolfSSL, mbedTLS — implementazioni embedded con supporto 1.3 in preparazione
• Go crypto/tls — supporto pianificato in Go 1.12 (febbraio 2019)

Nginx, Apache HTTP Server, HAProxy acquisiscono supporto TLS 1.3 con le nuove versioni di OpenSSL.

Adozione 2018-2020

Nei mesi successivi all’RFC:

• Browser — Firefox, Chrome, Safari, Edge supportano TLS 1.3 di default entro fine 2018
• Cloudflare, Fastly, Akamai — abilitano TLS 1.3 sulle edge CDN
• Google Search — serve TLS 1.3 di default
• Facebook — migrazione ampia
• Banche, e-commerce — graduale a seconda del policy compliance

La Qualys SSL Labs si aggiorna per testare la configurazione TLS 1.3 e indicarla nelle classi di grading.

Browser depreca TLS 1.0/1.1

In parallelo al rilascio di TLS 1.3, i principali browser (Microsoft, Google, Mozilla, Apple) annunciano ad ottobre 2018 il piano coordinato di deprecazione di TLS 1.0 e TLS 1.1 entro marzo 2020. L’annuncio congiunto accelera l’abbandono delle versioni vecchie: molti server che supportano solo TLS 1.0 vengono forzati ad aggiornamento.

Implicazioni per i prodotti

Per team di sviluppo e per i CISO aziendali:

• Compliance PCI-DSS — versioni 3.2 e successive richiedono TLS 1.2+ minimo
• FIPS 140-2/3 — aggiornamenti per allineare compliance governativa
• NIS2 (2022) e GDPR — richiedono “stato dell’arte” su crittografia, TLS 1.3 rientra
• AgID — indicazioni sulla sicurezza del software con TLS 1.2 minimo, 1.3 raccomandato
• Audit di TLS — strumenti come testssl.sh, sslyze, nmap --script ssl-enum-ciphers diventano standard nei pentest

Limiti residui

TLS 1.3 risolve molti problemi ma non tutti:

• Trust in Certificate Authorities — rimane sostanzialmente invariato; Certificate Transparency (RFC 6962) aiuta ma non sostituisce
• Encrypted SNI — il nome host nel ClientHello è ancora trasmesso in chiaro; ECH (Encrypted ClientHello) è in sviluppo IETF
• Post-quantum — TLS 1.3 non include algoritmi quantum-resistant; il lavoro di standardizzazione post-quantum è in corso (NIST competition, conclusa con CRYSTALS-Kyber, CRYSTALS-Dilithium nel 2022)

Nel contesto italiano

Al 2018 l’adozione italiana di TLS 1.3 è rapida per i grandi player (portali bancari, PA nazionale, telco) e graduale per PMI e amministrazioni locali. Le iniziative di miglioramento della postura TLS pubblica — portali AgID, Italia Login (SPID/CIE), Fascicolo Sanitario regionale — si allineano progressivamente a 1.2+ e poi 1.3 nel corso 2019-2021.

Riferimenti: RFC 8446 — “The Transport Layer Security (TLS) Protocol Version 1.3” (IETF, 10 agosto 2018). TLS Working Group, chair Eric Rescorla. OpenSSL 1.1.1 (settembre 2018). Deprecazione TLS 1.0/1.1 da parte dei browser (ottobre 2018 → marzo 2020). Qualys SSL Labs.