TLS 1.3 è oggi la versione di riferimento del Transport Layer Security per proteggere le comunicazioni tra client e server. La novità del 2026 non è una “TLS 1.4”, ma l’aggiornamento della specifica: a luglio l’IETF ha pubblicato RFC 9846, che mantiene la versione TLS 1.3, è compatibile con le implementazioni precedenti e sostituisce RFC 8446.

Per comprendere il percorso evolutivo e le differenze con TLS 1.2, Nexsys mantiene separata la guida TLS 1.2 vs TLS 1.3. Qui il focus è esclusivamente sul funzionamento e sulla sicurezza di TLS 1.3 nel 2026.

Che cos’è TLS e cosa protegge

TLS crea un canale cifrato e autenticato tra due endpoint. Durante l’handshake client e server negoziano versione, algoritmi, parametri crittografici e materiale di chiave; dopo il key exchange, i messaggi successivi dell’handshake vengono protetti con chiavi derivate e i dati applicativi viaggiano all’interno del canale cifrato.

TLS non coincide con HTTPS: HTTPS è HTTP trasportato su TLS. Lo stesso protocollo protegge anche altri servizi, inclusi SMTP, API, database e numerose comunicazioni applicative.

Cosa cambia davvero con TLS 1.3

• Handshake più corto: il full handshake standard può completare il key exchange in un round trip (1-RTT).
• Perfect Forward Secrecy come proprietà strutturale dei normali key exchange (EC)DHE: la compromissione futura della chiave privata del server non consente di decifrare retroattivamente le sessioni registrate.
• AEAD obbligatorio: TLS 1.3 usa suite moderne basate su AES-GCM o ChaCha20-Poly1305.
• Rimozione di molte opzioni legacy: niente static RSA key exchange, CBC in TLS 1.3, RC4 o renegotiation del modello precedente.
• Più handshake cifrato: dopo ServerHello, i messaggi di handshake sensibili vengono protetti.

RFC 9846: cosa aggiunge nel 2026

RFC 9846 è una revisione compatibile di TLS 1.3, ma introduce chiarimenti tecnici rilevanti. Tra le modifiche indicate dall’IETF: divieto di riutilizzare KeyShare tra connessioni, divieto di negoziare TLS 1.0 e 1.1, chiarimenti su Pre-Shared Key e HelloRetryRequest e requisiti più stringenti sull’aggiornamento delle chiavi prima di superare i limiti di utilizzo.

Handshake 1-RTT: perché TLS 1.3 riduce la latenza

Nel ClientHello il client può inviare subito una key share per il gruppo crittografico che prevede verrà accettato. Se il server supporta quel gruppo, può derivare il segreto condiviso senza un ulteriore round trip. Se i parametri non coincidono, il server può rispondere con HelloRetryRequest.

0-RTT: più veloce, ma non è sempre una buona idea

TLS 1.3 permette l’invio di early data in 0-RTT solo nelle connessioni riprese tramite PSK/session resumption. Il vantaggio è eliminare il round trip prima dei dati applicativi, ma gli early data non hanno le stesse proprietà anti-replay del traffico successivo.

Per questo 0-RTT deve essere limitato a richieste che possono essere ripetute senza effetti collaterali. Operazioni che cambiano stato, effettuano pagamenti o eseguono azioni sensibili non dovrebbero dipendere da early data senza adeguate protezioni anti-replay.

TLS 1.3 su Windows Server 2025

Windows Server 2025 e Windows 11 utilizzano Schannel come implementazione TLS di sistema. Microsoft documenta TLS 1.3 nello stack Schannel e, su Windows Server 2025, abilita di default le suite TLS_AES_256_GCM_SHA384 e TLS_AES_128_GCM_SHA256. TLS_CHACHA20_POLY1305_SHA256 è supportata ma non è abilitata di default nella priorità standard.

La configurazione dei protocolli e delle cipher suite deve essere effettuata preferibilmente tramite policy e strumenti supportati. Microsoft sconsiglia modifiche dirette al registro salvo necessità di troubleshooting o assenza di alternative.

Per scenari che richiedono ispezione TLS, firewall di nuova generazione o controllo del traffico cifrato, il tema va trattato come parte della Network Security aziendale, non come semplice attivazione di una versione del protocollo.

Come verificare se un endpoint supporta TLS 1.3

Con OpenSSL, su un sistema che dispone di una versione compatibile:

openssl s_client -connect www.example.com:443 -tls1_3

Il test deve mostrare una sessione negoziata in TLS 1.3 e la cipher suite effettivamente utilizzata. Per un controllo pubblico di server Web è possibile utilizzare anche scanner TLS esterni; in ambienti aziendali è preferibile verificare direttamente endpoint, reverse proxy, load balancer e apparati di sicurezza.

TLS 1.3 non risolve da solo tutti i problemi di sicurezza

• Un certificato scaduto o non attendibile resta un problema anche con TLS 1.3.
• Un endpoint può supportare TLS 1.3 e mantenere contemporaneamente versioni legacy per compatibilità.
• Proxy, load balancer, WAF e appliance di inspection possono terminare TLS e negoziare una versione diversa sul tratto successivo.
• Applicazioni legacy possono dipendere da TLS 1.2 o da cipher suite non più disponibili.
• 0-RTT deve essere valutato per il rischio replay.

Checklist di migrazione e hardening TLS

1. Inventaria endpoint, sistemi operativi, runtime, appliance, reverse proxy e load balancer.
2. Verifica quali servizi negoziano TLS 1.0/1.1 e rimuovi le dipendenze.
3. Mantieni TLS 1.2 dove necessario per compatibilità, ma con cipher suite moderne.
4. Abilita TLS 1.3 dove supportato e verifica la negoziazione reale.
5. Controlla certificate chain, scadenza, revoca e automazione del rinnovo.
6. Testa applicazioni e integrazioni prima di disabilitare protocolli legacy.
7. Monitora errori Schannel e handshake dopo il change.
8. Documenta eccezioni e data di rimozione delle compatibilità temporanee.

Per la gestione dei certificati Web e il rinnovo automatico, la guida Let’s Encrypt resta un approfondimento separato: il certificato abilita l’identità e la fiducia, mentre questa pagina rimane focalizzata sulla versione TLS e sul protocollo.