TLS, acronimo di Transport Layer Security, è il protocollo crittografico usato per creare un canale protetto tra due endpoint che comunicano attraverso una rete non fidata come Internet. Nel Web è il meccanismo che protegge HTTPS: permette al browser e al server di negoziare una connessione con confidenzialità, integrità e autenticazione.
La parte importante è capire il confine della tecnologia. TLS protegge il canale di comunicazione, ma non rende automaticamente sicuro il server, il sito o il dispositivo che si trova a una delle estremità. Un’applicazione vulnerabile può restare vulnerabile anche quando tutto il traffico viaggia correttamente su HTTPS.
In questa guida vediamo quindi come funziona il protocollo, cosa succede durante l’handshake, quale ruolo hanno certificati e chiavi, cosa cambia tra TLS 1.2 e 1.3 e perché TLS non va confuso con SSL, HTTPS o crittografia end-to-end.
Cos’è TLS e cosa protegge davvero
Transport Layer Security è progettato per permettere a client e server di comunicare in modo protetto anche quando i dati attraversano reti che non controllano direttamente. La specifica TLS 1.3 dell’IETF descrive il protocollo come un sistema pensato per impedire intercettazione, manomissione e falsificazione dei messaggi durante la comunicazione.
Nel caso più comune sul Web, il client è il browser e il server è il sistema che ospita il sito o un’infrastruttura intermedia autorizzata, come un reverse proxy o una CDN. Lo stesso modello può essere usato anche da API, servizi di posta, applicazioni, database e altri protocolli che hanno bisogno di proteggere dati in transito.
Crittografia, autenticazione e integrità
Per capire cosa offre il protocollo conviene separare tre proprietà che spesso vengono messe insieme.
Confidenzialità. Dopo che la sessione è stata stabilita, i dati applicativi vengono cifrati con chiavi note agli endpoint della connessione. Chi osserva il traffico lungo il percorso non dovrebbe quindi poter leggere direttamente il contenuto protetto.
Integrità. Il protocollo permette di rilevare modifiche non autorizzate ai dati protetti. Non basta infatti nascondere un messaggio: bisogna anche impedire che un intermediario possa alterarlo senza che gli endpoint se ne accorgano.
Autenticazione. In una normale connessione HTTPS il server dimostra la propria identità attraverso un certificato e una prova crittografica legata alla chiave privata corrispondente. Il client può così verificare di avere stabilito la sessione con un soggetto autorizzato per il nome richiesto. Il protocollo supporta anche l’autenticazione del client, ma sul Web pubblico non è normalmente il modello usato per la navigazione ordinaria.
Queste proprietà lavorano insieme. Una connessione cifrata ma priva di autenticazione potrebbe essere protetta rispetto a un osservatore passivo e, nello stesso tempo, terminare sull’interlocutore sbagliato.
Cosa significa proteggere i dati in transito
Il protocollo protegge i dati mentre attraversano il canale tra gli endpoint della sessione. Questo è diverso dalla cifratura dei dati a riposo, che riguarda file, database o backup memorizzati su un dispositivo o su un server.
È anche diverso dalla sicurezza dell’applicazione. Quando il server riceve e decifra legittimamente una richiesta HTTPS, i dati entrano nel perimetro dell’applicazione: da quel momento diventano rilevanti controlli di accesso, aggiornamenti, vulnerabilità del software, protezione del database e gestione delle credenziali.
Il modello corretto è quindi:
TLS → protegge il canale
sicurezza applicativa → protegge ciò che accade agli endpoint
cifratura a riposo → protegge i dati memorizzati
Sono livelli complementari, non sostituti.
TLS non è la stessa cosa della crittografia end-to-end
La distinzione con la crittografia end-to-end è particolarmente importante.
In una connessione protetta il server con cui viene stabilita la sessione è normalmente uno degli endpoint autorizzati e quindi può leggere i dati una volta decifrati. Se davanti all’applicazione è presente un reverse proxy, una CDN o un load balancer che termina la connessione, possono esistere più segmenti protetti separatamente: per esempio browser → edge e edge → server di origine.
La crittografia end-to-end adotta invece un obiettivo differente: fare in modo che il contenuto possa essere decifrato soltanto dagli endpoint finali autorizzati, senza concedere a un intermediario del servizio l’accesso in chiaro. È il modello che abbiamo approfondito nella guida sulla crittografia WhatsApp e sulla E2EE.
La conseguenza pratica è semplice: una connessione protetta in transito non è automaticamente end-to-end nel senso usato dalle app di messaggistica.
Dove si colloca TLS nello stack
Il nome Transport Layer Security può far pensare che il protocollo coincida con il livello di trasporto del modello OSI. È una semplificazione che conviene evitare.
Nel Web tradizionale puoi immaginare una pila del genere:
HTTP → TLS → TCP → IP
HTTP definisce richieste e risposte applicative. TCP fornisce il trasporto affidabile. Il livello crittografico crea il canale sicuro fra i due.
Con HTTP/3 il modello cambia, perché HTTP utilizza QUIC e QUIC integra la versione 1.3 come componente della sicurezza del trasporto. Per questo dire semplicemente che “TLS funziona sopra TCP” non è una definizione valida per ogni tecnologia moderna.
Come funziona TLS: handshake e connessione protetta
Una connessione non può iniziare cifrando immediatamente i dati con una chiave condivisa che client e server non hanno ancora concordato. Prima serve una fase iniziale in cui le parti negoziano il protocollo, stabiliscono materiale crittografico e, quando richiesto, verificano l’identità dell’altra parte.
Questa fase è il TLS handshake.
La versione 1.3 ha semplificato e riorganizzato il processo rispetto alle generazioni precedenti. Quello che segue è il modello di una normale connessione completa con autenticazione del server; session resumption, pre-shared key, autenticazione client e HelloRetryRequest possono modificare alcuni passaggi.
ClientHello: il client apre la negoziazione
Il primo messaggio inviato dal client è il ClientHello.
Tra le informazioni utili può indicare:
- le versioni del protocollo supportate;
- le cipher suite compatibili;
- gruppi crittografici e
key_sharedisponibili; - il nome del server attraverso SNI, quando necessario;
- i protocolli applicativi supportati attraverso ALPN, per esempio HTTP/2 o HTTP/3 nei contesti appropriati;
- eventuali dati per la ripresa di una sessione precedente.
Il punto chiave è che il client non sta semplicemente chiedendo “dammi il certificato”. Sta proponendo un insieme di capacità che permetterà al server di scegliere una configurazione compatibile.
ServerHello: il server sceglie i parametri comuni
Il server risponde con ServerHello, selezionando la versione e i parametri necessari per proseguire.
Nella normale negoziazione della versione 1.3, il contributo del server allo scambio di chiavi consente alle due parti di derivare segreti condivisi senza trasmettere direttamente sulla rete la futura chiave con cui verrà cifrata l’intera sessione.
Nelle connessioni web basate su certificato si usano comunemente scambi di chiavi effimeri, come ECDHE. Questo è un passaggio da capire bene: la chiave pubblica contenuta nel certificato non viene usata per cifrare ogni pagina, immagine o richiesta HTTP. Serve soprattutto all’autenticazione; le chiavi che proteggono il traffico vengono derivate durante l’handshake.
Certificato e autenticazione del server
Dopo aver stabilito i segreti necessari a proteggere il resto dell’handshake, il server presenta normalmente il certificato e dimostra di possedere la chiave privata associata.
Il client può verificare, fra le altre cose:
- che il certificato sia valido per il nome richiesto;
- che non sia fuori dal periodo di validità;
- che la catena di certificazione conduca a una Certification Authority considerata attendibile;
- che la firma e gli algoritmi utilizzati siano compatibili con la policy del client;
- che la prova crittografica del server sia coerente con la chiave pubblica del certificato.
Se vuoi approfondire SAN, Certification Authority, DV/OV/EV, catena di fiducia e rinnovo, l’owner corretto di quell’intento è la guida su cos’è e come funziona un certificato SSL/TLS.
Finished: entrambe le parti verificano l’handshake
Client e server scambiano messaggi Finished che autenticano crittograficamente la trascrizione dell’handshake. Questo consente a ciascuna parte di verificare che i messaggi negoziati non siano stati alterati e che l’altra parte possieda i segreti corretti.
Dopo il completamento della negoziazione, il traffico applicativo può essere inviato attraverso il canale protetto.
Se durante questi passaggi certificato, versioni, parametri, firme o chiavi non risultano compatibili, la connessione può interrompersi prima dello scambio dei normali dati applicativi.
Il Record Protocol protegge i dati dopo l’handshake
Una volta stabilita la sessione, non viene ripetuto l’intero handshake per ogni richiesta HTTP. Entra in gioco il livello record del protocollo, che frammenta e protegge i dati applicativi utilizzando le chiavi derivate per quella connessione.
La versione 1.3 usa algoritmi AEAD, cioè Authenticated Encryption with Associated Data, che combinano cifratura e verifica dell’integrità in una costruzione autenticata. Le cipher suite della versione 1.3 sono anche più semplici da interpretare rispetto al modello della versione 1.2, perché non includono nello stesso nome tutte le scelte relative a scambio di chiavi e autenticazione.
Questa separazione è uno dei motivi per cui leggere una configurazione della versione 1.3 con il modello mentale delle vecchie cipher suite può portare a conclusioni sbagliate.
TLS, SSL, HTTPS e certificati: quali sono le differenze
I quattro termini vengono spesso usati come se indicassero la stessa cosa, ma descrivono componenti diversi.
| Termine | Che cos’è | Funzione principale | È ancora il riferimento moderno? |
|---|---|---|---|
| TLS | Protocollo crittografico | Protegge il canale tra endpoint | Sì |
| SSL | Predecessore di TLS | Vecchio protocollo di sicurezza | No, è legacy |
| HTTPS | HTTP protetto tramite TLS | Trasporta richieste e risposte HTTP su un canale sicuro | Sì |
| Certificato SSL/TLS | Certificato digitale, normalmente X.509 | Associa identità e chiave pubblica e supporta l’autenticazione | Sì, anche se “SSL” è un nome storico |
La distinzione più utile è questa: il certificato aiuta a dimostrare con chi stai parlando; il protocollo costruisce e protegge la sessione; HTTPS usa quella protezione per HTTP.
SSL vs TLS: perché si parla ancora di “certificato SSL”
SSL, Secure Sockets Layer, è il predecessore storico di Transport Layer Security. Le versioni SSL non sono il protocollo da usare oggi, ma il nome è rimasto nel linguaggio commerciale di hosting, pannelli di controllo e certificati.
Per questo un provider può venderti o attivarti un “certificato SSL” anche se la connessione reale utilizza le versioni 1.2 o 1.3.
Non serve quindi correggere ossessivamente il termine ogni volta che compare. Serve però essere tecnicamente precisi quando parliamo del protocollo: SSL e il suo successore non sono due tipi di certificato.
TLS vs HTTPS: protocollo di sicurezza e protocollo applicativo
HTTPS è HTTP utilizzato attraverso una protezione crittografica basata sul protocollo. La semantica delle richieste e risposte resta HTTP: cambiano il modo in cui viene stabilito il canale e le proprietà di sicurezza offerte durante il trasporto.
Se vuoi vedere la separazione fra protocollo applicativo, sicurezza, HTTP/2, HTTP/3 e migrazione di un sito, la guida dedicata a HTTP vs HTTPS tratta quell’intento senza duplicare il funzionamento interno del protocollo.
Certificato TLS: cosa fa e cosa non fa
Il certificato non “cifra il sito” da solo e non contiene la chiave privata del server. Fornisce invece al client informazioni firmate che permettono di associare una chiave pubblica a un’identità, normalmente un dominio, e di verificare la catena di fiducia prevista dal sistema PKI.
La chiave privata resta separata e deve essere protetta dal soggetto che controlla il server o il sistema di terminazione.
Un certificato perfettamente valido non dimostra però che il sito sia onesto, privo di malware o immune da vulnerabilità. Dimostra qualcosa di molto più specifico: che il client ha elementi crittografici per autenticare l’endpoint secondo la policy applicata alla connessione.
TLS 1.2 e TLS 1.3: quali versioni contano oggi
Le versioni del protocollo non vanno trattate come semplici numeri progressivi intercambiabili.
Le versioni 1.0 e 1.1 sono state formalmente deprecate dalla RFC 8996 e non dovrebbero essere negoziate. La baseline moderna parte quindi almeno dalla generazione 1.2, mentre la direzione corrente dell’IETF privilegia TLS 1.3.
La BCP 195 raccoglie le raccomandazioni correnti sull’uso sicuro del protocollo e oggi include anche la RFC 9852, che richiede ai nuovi protocolli che impiegano questo standard di adottare TLS 1.3 come default. La versione 1.2 può ancora essere prevista come opzione aggiuntiva quando la compatibilità lo rende necessario, ma non è più il riferimento progettuale da scegliere per un nuovo protocollo.
Perché TLS 1.0 e TLS 1.1 sono obsoleti
Le due versioni appartengono a una fase precedente dell’evoluzione della crittografia applicata a Internet e non supportano il set di primitive e costruzioni moderne richiesto dalle raccomandazioni attuali.
Mantenerle abilitate amplia inoltre la superficie di configurazione e crea la possibilità di negoziare un protocollo più debole quando non esiste una reale esigenza di interoperabilità.
Per un sistema moderno la domanda non dovrebbe quindi essere “come faccio a far funzionare TLS 1.0?”, ma “quale componente legacy mi sta ancora obbligando a dipendere da una versione deprecata?”.
Cosa cambia da TLS 1.2 a TLS 1.3
La versione 1.3 non è un semplice ritocco alla precedente. Ha rimosso scelte crittografiche obsolete, semplificato la negoziazione, cifrato una parte maggiore dell’handshake e ridotto il numero di round trip necessari per stabilire una nuova connessione.
In una normale connessione completa, la versione 1.3 può completare il setup crittografico con un round trip prima dello scambio dei dati applicativi, mentre meccanismi di ripresa della sessione possono ridurre ulteriormente il costo per client e server che hanno già comunicato.
La scelta della versione non va però isolata dal resto della configurazione. Un servizio può supportare la versione 1.3 e avere comunque certificati errati, endpoint vulnerabili, configurazioni incoerenti o software non aggiornato.
RFC 9846: la specifica corrente di TLS 1.3
TLS 1.3 è nato come standard IETF nel 2018 con RFC 8446, ma oggi il riferimento aggiornato è RFC 9846. La nuova specifica mantiene il nome della versione 1.3, obsoleta RFC 8446 e incorpora chiarimenti e requisiti accumulati negli anni di implementazione.
Questo dettaglio è importante perché evita un errore frequente nei contenuti tecnici: confondere la data in cui una versione è stata introdotta con la data della specifica corrente che la definisce.
Per chi amministra un normale sito, il passaggio da RFC 8446 a RFC 9846 non significa che debba “installare di nuovo la versione 1.3”. Significa che documentazione, librerie e policy moderne devono essere interpretate rispetto al riferimento IETF corrente e ai relativi aggiornamenti.
0-RTT: meno latenza, ma con un trade-off di sicurezza
La versione 1.3 permette in alcuni scenari di ripresa della sessione di inviare early data senza attendere un nuovo round trip completo. È il meccanismo comunemente associato a 0-RTT.
Il vantaggio è evidente su reti con RTT elevato: eliminare un viaggio di andata e ritorno può ridurre il tempo necessario prima di inviare dati applicativi. Se vuoi capire quanto pesa un round trip nelle prestazioni di rete, trovi un approfondimento specifico sul Round Trip Time (RTT).
Il compromesso è altrettanto importante. La specifica corrente chiarisce che i dati 0-RTT non dispongono di una protezione intrinseca completa contro i replay. Server e applicazioni devono quindi adottare strategie appropriate e non trattare come innocua qualsiasi operazione che possa essere ripetuta.
Per questo 0-RTT non significa semplicemente “connessione più veloce in ogni scenario”. È una funzione da usare quando il protocollo applicativo e l’operazione sono compatibili con il relativo modello di rischio.
Dove viene utilizzato TLS oltre a HTTPS
HTTPS è il caso più visibile, ma Transport Layer Security è un protocollo generale e può proteggere numerose comunicazioni applicative.
Web, API e servizi applicativi
Browser e server web sono l’esempio classico. Lo stesso vale per molte API esposte tramite HTTPS: il payload applicativo continua a essere definito dall’API e da HTTP, mentre il canale di trasporto viene protetto dal protocollo crittografico.
Questo non sostituisce autenticazione e autorizzazione dell’API. Un endpoint HTTPS può comunque accettare una richiesta da un utente che non dovrebbe avere accesso se il sistema applicativo gestisce male token, ruoli o permessi.
Email, database e altri protocolli
Il protocollo può essere utilizzato anche in protocolli di posta, accessi a database, messaggistica, directory service e molte altre comunicazioni client-server.
Alcuni protocolli prevedono una connessione protetta fin dall’inizio; altri hanno storicamente utilizzato meccanismi di upgrade come STARTTLS, in cui una connessione iniziale viene trasformata in una sessione protetta.
La presenza del protocollo non dice però automaticamente se la configurazione è corretta. Versione negoziata, autenticazione, gestione dei certificati e possibilità di downgrade dipendono dal protocollo applicativo e dall’implementazione concreta.
HTTP/3 e QUIC: perché il modello cambia
HTTP/1.1 e HTTP/2 vengono comunemente utilizzati con un canale protetto sopra TCP. HTTP/3 usa invece QUIC.
La RFC 9001 descrive come la versione 1.3 viene utilizzata come componente della sicurezza di QUIC. In questo caso non hai semplicemente “TLS sopra TCP”: QUIC incorpora l’handshake nel proprio meccanismo di connessione e usa il materiale crittografico prodotto durante la negoziazione per proteggere i pacchetti.
Questo spiega due cose.
La prima: HTTP/3 richiede TLS 1.3 o una versione successiva compatibile con i requisiti di QUIC, non la versione 1.2.
La seconda: si tratta di un protocollo di sicurezza riutilizzabile, ma il modo in cui viene integrato nello stack può cambiare in base al trasporto.
Cosa TLS non può proteggere
La parte più utile di una guida sulla sicurezza spesso non è l’elenco di ciò che una tecnologia fa, ma il confine oltre il quale smette di essere la soluzione corretta.
Un endpoint compromesso resta compromesso
Se un malware controlla il browser dopo che i dati sono stati decifrati, non ha bisogno di rompere il protocollo in rete. Lo stesso vale per un server compromesso che riceve legittimamente il traffico in chiaro dopo la terminazione della sessione.
La protezione crittografica riguarda il percorso fra endpoint. Non può impedire a un endpoint autorizzato ma compromesso di leggere ciò che deve elaborare.
È lo stesso principio per cui la crittografia end-to-end non rende sicuro un telefono già sbloccato da un attaccante: la crittografia protegge un determinato confine, non ogni componente del sistema.
Non corregge vulnerabilità applicative, phishing o credenziali rubate
Un sito di phishing può avere un certificato valido. Un’applicazione vulnerabile a SQL injection può essere servita perfettamente in HTTPS. Un account amministratore con password rubata può essere usato attraverso una connessione cifrata impeccabile.
Per questo l’icona di una connessione sicura non va interpretata come bollino di affidabilità globale.
La conclusione corretta è più limitata: il client ha stabilito una sessione crittograficamente protetta con l’endpoint autenticato secondo i controlli previsti.
Non protegge automaticamente i dati a riposo
Quando il server riceve una password, un documento o un numero di carta attraverso una sessione sicura, la sessione crittografica ha protetto il percorso. Non decide però come quell’informazione verrà memorizzata.
Se l’applicazione scrive dati sensibili in chiaro in un database esposto, la protezione del trasporto non risolve il problema.
Per lo stesso motivo backup, file system, storage cloud e log richiedono misure specifiche.
Non rende la comunicazione anonima
La cifratura del contenuto non equivale all’anonimato della connessione. Indirizzi IP e altri metadati di rete possono restare osservabili ai soggetti che partecipano al trasporto.
La versione 1.3 cifra gran parte dell’handshake, ma storicamente il ClientHello ha lasciato visibili informazioni sensibili come SNI. L’IETF ha standardizzato Encrypted ClientHello (ECH), che può proteggere SNI e altri campi del ClientHello quando client, DNS e infrastruttura server lo supportano correttamente.
ECH migliora la privacy di una parte della negoziazione, ma non trasforma questa protezione in una rete di anonimizzazione e non nasconde magicamente ogni metadato della connessione.
Come verificare TLS su un sito web
Per un utente normale il primo controllo consiste nel verificare che il sito venga caricato tramite HTTPS senza errori di certificato. Per chi gestisce un server, invece, è utile distinguere almeno quattro verifiche: certificato, versione negoziata, parametri crittografici e comportamento dei diversi client.
Cosa puoi controllare dal browser
I browser moderni permettono di visualizzare informazioni sulla connessione e sul certificato, anche se l’interfaccia cambia nel tempo e fra prodotti diversi.
Controlla almeno:
- che l’URL utilizzi
https://; - che il browser non mostri errori di certificazione;
- che il certificato copra il nome host visitato;
- che il periodo di validità e la catena risultino accettati;
- se gli strumenti del browser lo mostrano, quale versione del protocollo è stata negoziata.
Non fermarti però alla presenza del lucchetto o dell’icona equivalente. Se devi amministrare il sistema, serve una verifica lato protocollo.
Verificare la connessione con OpenSSL
Da un ambiente che include OpenSSL puoi ispezionare una connessione con un comando di questo tipo:
openssl s_client -connect esempio.it:443 -servername esempio.it
L’opzione -servername invia SNI, fondamentale quando più siti condividono lo stesso indirizzo IP.
Nell’output puoi controllare certificato presentato, catena, versione negoziata e cipher. Il comando non sostituisce un audit completo della configurazione, ma è molto utile per capire cosa sta succedendo realmente sulla connessione invece di affidarti soltanto al pannello hosting.
Se devi diagnosticare una singola versione puoi anche forzare il test con le opzioni supportate dalla tua versione di OpenSSL, per esempio -tls1_3 o -tls1_2.
Versione, certificato e configurazione del server sono problemi distinti
Un server può supportare la versione 1.3 e presentare un certificato scaduto. Può avere un certificato perfetto ma accettare configurazioni legacy indesiderate. Può essere configurato correttamente sull’origine e fallire dietro una CDN o un reverse proxy.
Quando analizzi una connessione, quindi, separa almeno:
- protocol version — quale versione viene negoziata;
- certificate validation — chi viene autenticato e con quale catena;
- key exchange e cipher — quali algoritmi proteggono la sessione;
- application path — dove termina la sessione e come prosegue il traffico verso il backend.
Questa distinzione riduce molti falsi positivi durante il troubleshooting.
Cosa fare quando l’handshake fallisce
Se il browser e il server non riescono a trovare una configurazione compatibile o la verifica dell’identità fallisce, la sessione può interrompersi durante la negoziazione.
Le cause possibili includono certificati scaduti o non validi per il nome, catene incomplete, incompatibilità di versione, problemi SNI, configurazioni di proxy/CDN e policy crittografiche non compatibili.
In quel caso non conviene trasformare questa guida in una lista generica di tentativi. Per la diagnosi operativa trovi una guida separata sull’errore SSL Handshake Failed, che possiede l’intento troubleshooting.
Domande frequenti su TLS
TLS 1.2 è ancora sicuro?
La versione 1.2 non va equiparata alle versioni 1.0 e 1.1, che sono deprecate. Può ancora offrire buone proprietà di sicurezza quando è configurato secondo raccomandazioni moderne, ma richiede più attenzione nelle scelte di cipher suite e policy. Per nuovi protocolli, la Best Current Practice IETF oggi richiede TLS 1.3 come default e considera la versione 1.2 un’eventuale opzione aggiuntiva per compatibilità.
TLS 1.3 è sempre migliore di TLS 1.2?
Per nuovi progetti il riferimento da preferire è la versione 1.3: semplifica la configurazione, rimuove primitive obsolete, protegge una parte maggiore dell’handshake e riduce la latenza di setup. In infrastrutture esistenti, però, la disattivazione immediata della versione 1.2 può avere conseguenze di interoperabilità. La decisione operativa va quindi presa considerando i client reali che devono collegarsi, senza riabilitare versioni legacy non necessarie.
TLS e SSL sono la stessa cosa?
No. SSL è la famiglia di protocolli precedente; il protocollo moderno è il suo successore. L’espressione “certificato SSL” è ancora comune, ma il certificato non determina da solo la versione del protocollo negoziata.
HTTPS usa sempre TLS?
Nel Web moderno, HTTPS indica HTTP protetto attraverso un meccanismo di trasporto autenticato e cifrato basato su TLS. Con HTTP/1.1 e HTTP/2 questo avviene normalmente tramite un canale sicuro su TCP; con HTTP/3 la sicurezza è integrata in QUIC utilizzando la versione 1.3.
Un certificato valido significa che il sito è sicuro?
No. Il certificato permette al client di autenticare l’endpoint secondo il modello PKI e partecipa alla creazione della sessione sicura. Non verifica il codice dell’applicazione, non esclude malware o phishing e non dimostra che i dati vengano conservati in modo sicuro dopo la ricezione.
TLS nasconde il sito che sto visitando?
Non completamente. Il protocollo protegge il contenuto della sessione, ma vari metadati di rete possono restare osservabili. ECH può cifrare SNI e altri elementi del ClientHello quando è supportato, ma non nasconde l’indirizzo IP di destinazione e non sostituisce strumenti progettati per l’anonimato.
Conclusione
Il protocollo permette a moltissime comunicazioni Internet di attraversare reti non fidate senza rinunciare a confidenzialità, integrità e autenticazione. Sul Web è ciò che rende possibile proteggere HTTP attraverso HTTPS, ma il protocollo viene usato anche in molti altri scenari client-server.
Il modello da ricordare è più utile di qualsiasi definizione mnemonica: il certificato contribuisce ad autenticare l’endpoint, l’handshake negozia e deriva le chiavi, il Record Protocol protegge i dati della sessione e l’applicazione continua a essere responsabile di ciò che accade agli endpoint.
Per configurazioni moderne, le versioni 1.0 e 1.1 non devono più essere negoziate. La versione 1.2 può ancora esistere per compatibilità in sistemi attuali configurati correttamente, mentre la versione 1.3 è il riferimento verso cui converge la Best Current Practice IETF e deve essere il default per i nuovi protocolli che usano questo standard.
E soprattutto, non confondere la sicurezza del canale con la sicurezza dell’intero sistema. Un sito HTTPS può avere vulnerabilità, un server può essere compromesso e un dispositivo può essere controllato da malware anche quando la connessione TLS è tecnicamente perfetta. Capire dove finisce la protezione del protocollo è il passaggio che permette di usarlo e valutarlo correttamente.