Qual è la differenza tra SSL e TLS?

Storicamente la stessa cosa. SSL era il nome di Netscape; TLS è il successore standardizzato IETF a partire dal 1999. L'uso colloquiale moderno spesso chiama tutto "SSL" anche se TLS è il protocollo effettivo da oltre 25 anni. Tutte le attuali connessioni Web sicure utilizzano TLS 1.2 o TLS 1.3.

Perché TLS 1.3 è più veloce?

Taglia l'handshake da due round trip a uno (1-RTT) inviando la chiave pubblica DH del client nel primo messaggio e raggruppando la risposta del server con tutti gli altri stati dell'handshake. La ripresa della sessione può anche iniziare a inviare i dati dell'applicazione con il primo messaggio (0-RTT). Su un collegamento con latenza di 100 ms, si tratta di un miglioramento percepito di 200 ms alla prima connessione.

TLS 1.2 è ancora sicuro nel 2026?

Sì, se configurato correttamente: crittografia AES-GCM o ChaCha20-Poly1305, scambio di chiavi ECDHE per segretezza diretta, nessuna crittografia in modalità CBC, nessuna RC4, nessun fallback SSL 3.0. TLS 1.3 rimuove completamente il rischio di configurazione eliminando le opzioni errate.

Cos'è il client crittografato Hello?

Un'estensione che crittografa il campo Server Name Indication (SNI) nell'handshake TLS. Senza ECH, la tua rete può vedere ogni dominio che visiti anche quando il resto della connessione è crittografato. ECH (e il precedente ESNI) nasconde l’ultimo pezzo di metadati, completando la storia della privacy iniziata da TLS nel 1994.

TLS è sicuro dal punto di vista quantistico?

Non ancora per impostazione predefinita, ma in fase di implementazione. Il Diffie-Hellman a curva ellittica X25519 standard è teoricamente distruttibile da un computer quantistico sufficientemente grande. La modalità ibrida X25519MLKEM768 (impostazione predefinita di Chrome dalla fine del 2024, crescente supporto dei browser) combina algoritmi classici e post-quantistici in modo che il traffico rimanga sicuro anche contro futuri aggressori quantistici.

TLS spiegato: il protocollo dietro ogni icona di lucchetto

Transport Layer Security è il fondamento crittografico di HTTPS, e-mail moderna, VPN, app di messaggistica e gran parte del traffico Internet nel 2026. È iniziato come SSL di Netscape nel 1994 e da allora è stato silenziosamente aggiornato otto volte. Questa è la spiegazione tecnica: come funziona l'handshake, cosa è cambiato in TLS 1.3, gli attacchi che lo hanno modellato e dove andrà dopo.

Il corpo completo dell'articolo è fornito in inglese di seguito.

SSL → TLS: la storia cronologica

Netscape Communications ha creato la prima implementazione SSL nel 1994 per proteggere gli acquisti online nel nuovissimo browser Netscape Navigator. SSL 1.0 non è mai stato rilasciato pubblicamente perché presentava difetti critici. SSL 2.0 distribuito nel febbraio 1995 fu prontamente interrotto e SSL 3.0 seguì nel 1996 come una riscrittura quasi totale.

Nel 1999 l'IETF prese il controllo del protocollo e lo rinominò Transport Layer Security per segnare la transizione da un prodotto Netscape a uno standard aperto. La cronologia delle versioni da:

TLS 1.0 (gennaio 1999, RFC 2246) — essenzialmente SSL 3.1.
TLS 1.1 (aprile 2006, RFC 4346) — protetto dagli attacchi CBC tramite inizializzazione esplicita vettori.
TLS 1.2 (agosto 2008, RFC 5246): aggiunti codici AEAD, SHA-256 e algoritmi di firma configurabili. Dominato per un decennio.
TLS 1.3 (agosto 2018, RFC 8446): importante riprogettazione. Rimosso il cruft legacy, la segretezza obbligatoria, ridotta la latenza dell'handshake.

SSL 3.0 è stato formalmente deprecato nel giugno 2015 (RFC 7568) dopo POODLE. TLS 1.0 e 1.1 sono stati ritirati nel marzo 2021 (RFC 8996). Nel 2026, i server moderni dovrebbero rifiutare qualsiasi cosa inferiore a TLS 1.2 e preferire TLS 1.3.

Come funziona effettivamente l'handshake

Ogni connessione TLS inizia con un handshake che fa tre cose: concordare una suite di crittografia, dimostrare l'identità del server e derivare chiavi condivise per il resto della sessione.

TLS 1.2 handshake (il flusso classico)

ClientHello: il client invia versioni TLS supportate, suite di crittografia e un numero casuale.
ServerHello: il server sceglie una suite di crittografia, invia la sua suite di crittografia casuale number.
Certificate: il server invia la catena di certificati X.509 in modo che il client possa verificare l'identità.
ServerKeyExchange: il server invia la chiave pubblica Diffie-Hellman (per la chiave temporanea exchange).
ClientKeyExchange: il client invia la sua chiave pubblica DH. Entrambe le parti ora derivano lo stesso segreto condiviso.
Finito: entrambe le parti confermano l'handshake inviando un MAC sull'intera trascrizione.

Sono due viaggi di andata e ritorno completi prima che possa fluire il primo byte dell'applicazione. Su un collegamento con latenza di 100 ms, ogni nuova connessione HTTPS consuma 200 ms prima che qualsiasi contenuto effettivo venga spostato.

TLS 1.3 handshake (il flusso moderno)

TLS 1.3 comprime l'handshake in un viaggio di andata e ritorno nel comune case:

ClientHello: include la chiave pubblica DH del client per ogni gruppo di crittografia supportato dal client.
ServerHello + tutto il resto: il server seleziona un gruppo, invia la chiave pubblica DH, il certificato e il risultato finale, tutto in uno flight.
Client convalida e risponde con il proprio Finished.

Un viaggio di andata e ritorno, due voli. Con la ripresa della sessione (0-RTT), il client può persino iniziare a inviare dati con il suo primo messaggio, al costo di alcune proprietà di forward-secrecy per quei dati iniziali.

What TLS 1.3 rimossoL'altra grande mossa di

TLS 1.3 è stata l'eliminazione. Sono usciti:

Static RSA key exchange (ha rotto la segretezza).
CBC modalità cifrari (vulnerabile a BEAST e Lucky Thirteen).
RC4 cifrario a flusso (da tempo rotto).
MD5 e hash SHA-1 per firme.
Rinegoziazione (sostituita dall'autenticazione post-handshake).
Compressione (classe di attacchi CRIME).
Parametri Diffie-Hellman personalizzati (correzione Logjam).

L'elenco delle suite di crittografia è passato da circa 300 in TLS 1.2 a 5 in TLS 1.3. Meno corda con cui impiccarsi.

La cronologia degli attacchi che ha plasmato TLS

BEAST (2011): attacco con testo in chiaro scelto in modalità CBC in TLS 1.0. Risolto il problema nella versione 1.1+ tramite IVs.
CRIME (2012) esplicito: utilizzava la compressione TLS per recuperare i cookie di sessione. Risolto disabilitando la compressione.
BREACH (2013): compressione a livello HTTP equivalente a CRIME. Mitigato disabilitando la compressione HTTP sulle risposte sensibili.
Heartbleed (aprile 2014): bug OpenSSL, non un problema di specifiche TLS. Memoria del server trapelata, comprese le chiavi private. Evento di rotazione di massa dei certificati sul web.
POODLE (ottobre 2014): fallback SSL 3.0 sfruttato. Ha eliminato SSL 3.0 nei browser in poche settimane.
Logjam (2015) — ha dimostrato che piccoli gruppi Diffie-Hellman (in particolare il Gruppo 2 a 1024 bit ampiamente utilizzato in IPsec/IKE) erano alla portata degli aggressori di stati-nazione. Migrazione forzata a livello di settore verso gruppi più grandi e curva ellittica DH.
Lucky Thirteen (2013): attacco temporale in modalità CBC. Correzione a livello di libreria in OpenSSL e altri.

Ogni attacco ha rafforzato il protocollo. Con TLS 1.3 la maggior parte di queste classi sono impossibili in base alla progettazione.

Autorità di certificazione e problema di attendibilitàL'autenticazione

TLS si basa su autorità di certificazione (CA) di cui i browser si fidano per impostazione predefinita. I primi tre per quota di mercato dal 2019: IdenTrust, DigiCert e Sectigo. Let's Encrypt, la CA gratuita e automatizzata lanciata nel 2016, ha guidato la più grande spinta all'adozione nella storia di HTTPS.

La debolezza strutturale: qualsiasi CA attendibile può emettere un certificato per qualsiasi dominio. Una CA compromessa o costretta può coniare un certificato valido per la tua banca. Per rilevare questo problema sono stati introdotti i registri Certificate Transparency (CT), ovvero record pubblici di sola aggiunta di ogni certificato mai emesso. I browser ora richiedono che i certificati appaiano nei registri CT prima di poterli accettare.

LIl CA/Browser Forum ha approvato la riduzione della validità massima del certificato a 47 giorni entro il 2029, restringendo la finestra durante la quale una CA compromessa può causare danni.

Encrypted Client Hello (ECH)

Una cosa classica che viene divulgata da TLS: il campo Server Name Indication (SNI) in ClientHello, che indica al server a quale nome host ti stai connettendo in modo che possa presentare il certificato corretto. SNI è in chiaro, quindi gli osservatori della rete apprendono ogni dominio che visiti anche se il resto della connessione è crittografato.

Encrypted Client Hello (ECH), un'evoluzione della precedente proposta ESNI, crittografa l'SNI utilizzando una chiave pubblica pubblicata dalla destinazione tramite DNS. Cloudflare e Apple hanno fornito il supporto ECH; Firefox e Chrome lo hanno implementato dietro flag fino al 2024 e si stanno muovendo verso l'attivazione predefinita. Per gli utenti su reti ostili, ECH è il prossimo aggiornamento della privacy dopo l'HTTPS universale.

DTLS — TLS per UDP

DTLS (Datagram TLS) è la variante TLS che funziona su UDP. Alimenta WebRTC (video/voce del browser), la sicurezza sottostante di QUIC e diversi protocolli VPN. DTLS 1.3 (RFC 9147, 2022) corrisponde alle modernizzazioni dell'handshake e della crittografia di TLS 1.3.

Post-quantum TLS

Lo scambio di chiavi Diffie-Hellman, la base della segretezza diretta di TLS, è violabile da un computer quantistico sufficientemente grande. La soluzione è lo scambio di chiavi ibrido che combina un algoritmo classico (X25519) con un candidato post-quantistico (tipicamente ML-KEM-768, precedentemente noto come Kyber).

Chrome ha abilitato l'ibrido X25519MLKEM768 per impostazione predefinita alla fine del 2024. Cloudflare, Apple iCloud e diversi provider VPN lo hanno distribuito fino al 2025. L'implementazione più ampia protegge il traffico odierno dal Attacco "raccogli ora, decrittografa dopo": un avversario che registra il traffico crittografato oggi, in attesa dei computer quantistici, quindi lo decrittografa cronologicamente.

Come verificare il TLS utilizzato effettivamente dal tuo browser

Fai clic sul lucchetto nella barra degli indirizzi del browser. I browser moderni mostrano la versione del protocollo, la suite di crittografia e i dettagli del certificato. Se vedi TLS 1.0 o 1.1, il sito utilizza configurazioni deprecate. Se vedi TLS 1.3 con AES-256-GCM o ChaCha20-Poly1305, sei sulla crittografia moderna.

La tecnologia complementare HTTPS, , trattata nella nostra spiegazione HTTPS, è ciò che avvolge il Web in TLS. I due termini sono spesso usati in modo intercambiabile colloquialmente, ma TLS è il protocollo crittografico sottostante; HTTPS è semplicemente HTTP-over-TLS.

Domande frequenti

Qual è la differenza tra SSL e TLS?: Storicamente la stessa cosa. SSL era il nome di Netscape; TLS è il successore standardizzato IETF a partire dal 1999. L'uso colloquiale moderno spesso chiama tutto "SSL" anche se TLS è il protocollo effettivo da oltre 25 anni. Tutte le attuali connessioni Web sicure utilizzano TLS 1.2 o TLS 1.3.
Perché TLS 1.3 è più veloce?: Taglia l'handshake da due round trip a uno (1-RTT) inviando la chiave pubblica DH del client nel primo messaggio e raggruppando la risposta del server con tutti gli altri stati dell'handshake. La ripresa della sessione può anche iniziare a inviare i dati dell'applicazione con il primo messaggio (0-RTT). Su un collegamento con latenza di 100 ms, si tratta di un miglioramento percepito di 200 ms alla prima connessione.
TLS 1.2 è ancora sicuro nel 2026?: Sì, se configurato correttamente: crittografia AES-GCM o ChaCha20-Poly1305, scambio di chiavi ECDHE per segretezza diretta, nessuna crittografia in modalità CBC, nessuna RC4, nessun fallback SSL 3.0. TLS 1.3 rimuove completamente il rischio di configurazione eliminando le opzioni errate.
Cos'è il client crittografato Hello?: Un'estensione che crittografa il campo Server Name Indication (SNI) nell'handshake TLS. Senza ECH, la tua rete può vedere ogni dominio che visiti anche quando il resto della connessione è crittografato. ECH (e il precedente ESNI) nasconde l’ultimo pezzo di metadati, completando la storia della privacy iniziata da TLS nel 1994.
TLS è sicuro dal punto di vista quantistico?: Non ancora per impostazione predefinita, ma in fase di implementazione. Il Diffie-Hellman a curva ellittica X25519 standard è teoricamente distruttibile da un computer quantistico sufficientemente grande. La modalità ibrida X25519MLKEM768 (impostazione predefinita di Chrome dalla fine del 2024, crescente supporto dei browser) combina algoritmi classici e post-quantistici in modo che il traffico rimanga sicuro anche contro futuri aggressori quantistici.