Che cos'è TLS? Come HTTPS protegge il traffico

#La risposta breve

TLS (Transport Layer Security) è un protocollo che avvolge una connessione di rete nella cifratura. HTTPS è normale HTTP inviato dentro una connessione TLS. Quando il browser mostra il lucchetto, ha fatto tre cose. Ha cifrato i dati. Ha controllato che nessuno li abbia modificati in transito. E ha verificato che il server abbia dimostrato di possedere un certificato ritenuto affidabile per il nome che hai digitato.

Il terzo punto è quello che molti leggono male. HTTPS ti dice con quale server stai parlando. Non dice nulla sul fatto che quel server sia affidabile, onesto o ben gestito.

#Perché il semplice HTTP non basta

In Come funziona HTTP, richieste e risposte sono messaggi di testo, e HTTP non fa nulla per nasconderli. Ogni dispositivo tra te e il server può leggerli: il router di casa, l'access point di un bar, il tuo operatore internet e le reti intermedie.

Un osservatore passivo può leggere un modulo di accesso inviato in HTTP semplice. Un attaccante attivo sul percorso può fare di più: modificare una pagina prima che ti arrivi, inserire uno script o sostituire un download con un file alterato. TLS è progettato per fermare entrambe le minacce. Dà anche al client un modo per controllare chi sta rispondendo, cosa che il semplice HTTP non fa mai.

#Che cosa dà TLS 1.3

La versione attuale è TLS 1.3, definita nella RFC 8446. TLS 1.0 e 1.1 sono deprecati, come spiega la RFC 8996, e TLS 1.2 è ancora molto diffuso. La versione 1.3 ha tolto molte opzioni vecchie, quindi ci sono meno modi di configurare male l'handshake.

TLS 1.3 ti dà tre proprietà.

#Riservatezza

I dati applicativi sono cifrati con chiavi di sessione che solo i due endpoint possiedono. Un osservatore vede testo cifrato. La dimensione e i tempi del traffico restano visibili, il contenuto no.

Un handshake TLS 1.3 completo usa uno scambio di chiavi effimero. Le due parti creano valori di chiave temporanei per la sessione e poi li scartano. Questo dà la forward secrecy: se la chiave privata del certificato del server trapela anni dopo, le vecchie sessioni registrate dovrebbero restare illeggibili. Una chiave trapelata permette comunque a un attaccante di impersonare il server da quel momento in poi, quindi la forward secrecy protegge il passato e non il futuro.

#Integrità

Ogni record porta un tag di autenticazione generato da un cifrario AEAD, come AES-GCM o ChaCha20-Poly1305. TLS 1.3 ammette solo questo tipo di cifrario. Se un attaccante inverte un bit in transito, il controllo del tag fallisce e il record viene rifiutato.

#Autenticazione del server

Il server dimostra di possedere la chiave privata corrispondente al suo certificato. Il certificato lega quella chiave pubblica a un nome come example.com. Il client controlla il certificato e la catena di fiducia che lo sostiene, poi controlla il nome. Il resto dell'articolo parla in gran parte di questo.

#L'handshake, passo per passo

L'handshake concorda le chiavi e dimostra l'identità prima che si muova qualsiasi dato HTTP. In TLS 1.3 l'handshake abituale richiede un solo round trip. I passi qui sotto seguono la RFC 8446 a grandi linee.

#Passo 1: il ClientHello

Il client invia un ClientHello. Elenca le versioni di TLS e le cipher suite che accetta, e include una key share, il valore pubblico temporaneo del client per lo scambio di chiavi. Porta anche la server name indication (SNI), il nome host che hai chiesto, in chiaro. I server che ospitano molti siti hanno bisogno di quel nome per scegliere il certificato giusto.

#Passo 2: il ServerHello

Il server sceglie una versione e una cipher suite e invia la propria key share. Ciascuna parte combina il proprio valore privato con il valore pubblico dell'altra e ricava lo stesso segreto condiviso. Un osservatore che ha visto entrambi i valori pubblici non può calcolare quel segreto. Da qui in poi l'handshake è cifrato.

#Passo 3: il certificato e la prova

Il server invia il suo certificato. In TLS 1.2 il certificato era visibile sulla rete. In TLS 1.3 viaggia nella parte cifrata dell'handshake.

Il server invia poi un messaggio CertificateVerify, una firma sulla trascrizione dell'handshake fatta con la chiave privata del certificato. Questo dimostra che il server possiede la chiave durante questo handshake. Un certificato copiato, da solo, non serve a nulla a un attaccante. Un messaggio Finished, un MAC sulla trascrizione, chiude la parte del server.

#Passo 4: il client controlla e chiude

Il client controlla la catena di certificati, le date di validità, il nome nel certificato rispetto all'host richiesto e la firma CertificateVerify. Se ogni controllo va a buon fine, il client invia il proprio messaggio Finished e i dati applicativi possono passare.

Se un controllo fallisce, il client si ferma. Un browser mostra un avviso sul certificato, e curl esce con un errore. Per chi comincia, quei messaggi sono la parte più utile di TLS, perché nominano il controllo fallito.

#Certificati e catene di fiducia

Un certificato è una struttura X.509, e la RFC 5280 definisce il profilo usato su internet. Questi sono i campi che contano di più qui.

I client moderni ignorano il Common Name (CN) nel subject per il controllo del nome host e usano l'elenco SAN. Chi guarda solo il CN può giudicare male un certificato.

#Come si controlla la catena

Un server presenta di rado un certificato che il client può verificare direttamente. Di solito il certificato foglia, che copre il nome host, è firmato da una CA intermedia, e la CA intermedia è firmata da una CA radice. Il client si fida di un insieme di CA radice fornito con il sistema operativo o con il browser.

Il client costruisce un percorso dal certificato foglia a una CA radice fidata. A ogni anello verifica la firma, controlla le date di validità e conferma che l'emittente possa firmare certificati. Poi controlla il nome host. Entrambi i controlli devono passare.

Qualsiasi CA radice fidata può, in linea di principio, emettere un certificato per qualsiasi nome. La fiducia dipende quindi dalle pratiche delle autorità presenti nello store. Per questo i vendor rimuovono le autorità che emettono certificati in modo scorretto.

#Revoca

Un certificato può essere revocato prima della scadenza, per esempio dopo la compromissione della sua chiave. I client possono controllare la revoca con le certificate revocation list (CRL) o con OCSP, ma questi controlli non funzionano ovunque allo stesso modo. Una connessione andata a buon fine non dimostra che un certificato non sia mai stato revocato.

#Che cosa TLS non protegge

#Il server

TLS autentica l'identità del server, ma non ne valuta il comportamento. Un sito di phishing può ottenere un certificato valido per un dominio somigliante che controlla. Il lucchetto mostra allora che la connessione arriva a chi possiede la chiave di quel dominio, non che il dominio appartenga alla tua banca. Leggi il nome host nella barra degli indirizzi prima di fidarti della pagina. Anche un server con un certificato corretto può essere violato o gestito male.

#I metadati

TLS nasconde il contenuto, non tutto ciò che riguarda la connessione. Chiunque sia sul percorso può comunque vedere gli indirizzi IP alle due estremità, la porta, la dimensione e i tempi approssimativi del traffico e il nome del server nel ClientHello, perché la SNI viaggia in chiaro. Encrypted Client Hello è un'iniziativa dell'IETF per nascondere la SNI, ma controlla quanto è diffuso prima di dare per scontato che un sito lo usi. Le risoluzioni DNS passano per un protocollo separato e rivelano i nomi che risolvi, a meno che tu non usi DNS cifrato.

#Gli endpoint

TLS protegge i dati mentre si spostano tra due endpoint. Gli endpoint restano scoperti. Un malware sul tuo computer può leggere i dati decifrati, e un'estensione del browser può leggere ogni pagina che apri. Un'azienda può anche installare una propria CA radice fidata sulla tua macchina e decifrare il tuo traffico HTTPS tramite un proxy di ispezione. Il client funziona allora esattamente come è stato configurato, e la decisione sulla fiducia spetta a chi controlla il root store.

#Lab pratico: ispeziona HTTPS verso example.com

example.com è uno dei nomi che IANA riserva a documentazione ed esempi. Ogni comando qui sotto si collega solo a example.com. Il lab non cambia nulla sul server e non richiede un account. Ti serve un terminale con curl e openssl. I comandi openssl sono stati eseguiti con OpenSSL 3.2.4.

Il tuo output sarà diverso da quello mostrato qui. Gli indirizzi IP cambiano, i certificati si rinnovano e le date vanno avanti.

#Passo 1: leggi lo scambio con curl

curl -vI https://example.com

Il flag -v stampa i dettagli della connessione, e -I invia una richiesta HEAD, che chiede solo gli header. Sulla macchina usata per questo articolo (Windows 11 con Git Bash, curl 8.12.1, eseguito l'8 novembre 2026), le righe rilevanti erano queste:

* Host example.com:443 was resolved.
* IPv4: 172.66.147.243, 104.20.23.154
* Connected to example.com (172.66.147.243) port 443
* using HTTP/1.x
> HEAD / HTTP/1.1
> Host: example.com
< HTTP/1.1 200 OK

Questa build di curl usa Schannel, la libreria TLS di Windows, e il suo output verbose è diverso da quello di curl compilato con OpenSSL. Qui curl non ha stampato le righe su versione TLS, cifrario o certificato che questo lab cerca. Con un curl basato su OpenSSL, cerca la riga che nomina la versione TLS e il cifrario, e il blocco del certificato con subject, issuer e data di scadenza. I passi successivi ricavano gli stessi dati con openssl.

Il 200 OK significa che il server ha risposto dentro la connessione TLS. Gli header viaggiano cifrati, e curl li decifra in locale.

#Passo 2: ottieni un breve riepilogo con openssl

openssl s_client -connect example.com:443 -servername example.com -brief </dev/null

Output:

Connecting to 172.66.147.243
CONNECTION ESTABLISHED
Protocol version: TLSv1.3
Ciphersuite: TLS_AES_256_GCM_SHA384
Peer certificate: CN=example.com
Hash used: SHA256
Signature type: ECDSA
Verification: OK
Server Temp Key: X25519, 253 bits
DONE

Leggilo riga per riga:

• Protocol version: la versione di TLS negoziata per questa connessione.
• Ciphersuite: AES-256-GCM protegge i record, e SHA-384 si usa nel key schedule.
• Signature type: ECDSA, l'algoritmo della chiave del certificato.
• Verification: OK, cioè la catena è stata convalidata con il trust store di questa build di openssl.
• Server Temp Key: X25519, lo scambio di chiavi effimero che dà la forward secrecy.

Il flag -servername imposta la SNI. Senza, un server che ospita più siti può restituire un certificato predefinito che non corrisponde al nome che volevi. Il reindirizzamento </dev/null chiude lo standard input così il comando termina.

#Passo 3: leggi i campi del certificato

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates

Output:

subject=CN=example.com
issuer=C=US, O=SSL Corporation, CN=Cloudflare TLS Issuing ECC CA 3
notBefore=Sep 26 22:49:11 2026 GMT
notAfter=Dec 25 22:56:35 2026 GMT

Il subject contiene solo un CN. L'issuer è una CA intermedia, non una radice. L'intervallo di validità era aperto il giorno del lab e si chiude il 25 dicembre 2026. Confronta notAfter con la data del tuo sistema, perché un certificato scaduto fallisce anche quando la sua catena è integra.

Il subject non elenca i nomi coperti, quindi chiedi l'elenco SAN:

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -ext subjectAltName

Output:

X509v3 Subject Alternative Name:
    DNS:example.com, DNS:*.example.com

Il wildcard copre nomi come www.example.com. Il client confronta questo elenco con l'host del tuo URL.

#Passo 4: elenca la catena inviata dal server

openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null 2>/dev/null | grep -E '^ *[0-9] s:|^ *i:'

Output:

 0 s:CN=example.com
   i:C=US, O=SSL Corporation, CN=Cloudflare TLS Issuing ECC CA 3
 1 s:C=US, O=SSL Corporation, CN=Cloudflare TLS Issuing ECC CA 3
   i:C=US, O=SSL Corporation, CN=SSL.com TLS Transit ECC CA R2
 2 s:C=US, O=SSL Corporation, CN=SSL.com TLS Transit ECC CA R2
   i:C=US, O=SSL Corporation, CN=SSL.com TLS ECC Root CA 2022
 3 s:C=US, O=SSL Corporation, CN=SSL.com TLS ECC Root CA 2022
   i:C=GB, ST=Greater Manchester, L=Salford, O=Comodo CA Limited, CN=AAA Certificate Services

Ogni riga s: è un subject e ogni riga i: è il suo issuer. La voce 0 è il certificato foglia, e ogni voce è emessa da quella successiva. I certificati possono avere firme incrociate, quindi una catena può arrivare a una radice per più di un percorso. Al client serve un percorso valido che finisca in una radice del suo store.

#Passo 5: conferma che la catena supera la verifica

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | grep 'Verify return code'

Output:

Verify return code: 0 (ok)

Zero significa che il trust store di questa build di openssl ha accettato la catena. Altri valori indicano un errore preciso, come un certificato scaduto.

#Passo 6: fai fallire di proposito il controllo del nome

openssl s_client -connect example.com:443 -servername example.com -verify_hostname example.org -brief </dev/null

Output, accorciato:

depth=0 CN=example.com
verify error:num=62:hostname mismatch
CONNECTION ESTABLISHED
Protocol version: TLSv1.3
Ciphersuite: TLS_AES_256_GCM_SHA384
Peer certificate: CN=example.com
Verification error: hostname mismatch

Il comando continua a collegarsi solo a example.com. Il flag -verify_hostname chiede a openssl di controllare il certificato rispetto a example.org, che il certificato non copre. Un browser mostra lo stesso tipo di errore. È questo controllo che impedisce a un server con un certificato valido per un dominio di spacciarsi per un altro.

#Che cosa ricavare dal lab

La connessione ha negoziato TLS 1.3, e il client ha accettato una catena per example.com rifiutando lo stesso certificato per example.org. Nessuno dei due risultati dice se l'azienda dietro example.com sia affidabile. Il lab mostra che il tuo client ha raggiunto chi possiede la chiave di example.com, e nient'altro.

#Errori comuni

• Leggere il lucchetto come un giudizio di affidabilità. Significa che il canale è cifrato e che il certificato ha superato i controlli. Non valuta il sito.
• Controllare solo il CN. I client moderni confrontano il nome host con l'elenco SAN.
• Ignorare un avviso sul certificato e andare avanti. L'avviso significa che un controllo è fallito. Capisci quale prima di continuare.
• Aggiungere -k o --insecure a curl per far sparire un errore. Così disattivi i controlli che hai appena letto. Usalo solo contro un server di prova usa e getta, mai con credenziali reali.
• Scrivere codice con la verifica disattivata, come verify=False in un client HTTP Python. I dati restano cifrati, ma per chiunque abbia risposto.

#Per andare oltre

Leggi le sezioni di panoramica e di handshake della RFC 8446, poi scorri la RFC 5280 per i campi del certificato. Leggi la guida di Mozilla su TLS lato server ed esegui un controllo di configurazione su un server che gestisci tu.

Il prossimo articolo di questa serie parla delle chiavi pubbliche e private, la matematica dietro il certificato. Se il passaggio della risoluzione dei nomi ti è nuovo, leggi prima Che cos'è il DNS?, perché il suo risultato decide a quale indirizzo arriva l'handshake.

#Fonti

• RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3
• RFC 5280: Internet X.509 Public Key Infrastructure Certificate and CRL Profile
• Mozilla: Security/Server Side TLS
• OpenSSL documentation: openssl-s_client
• RFC 8996: Deprecating TLS 1.0 and TLS 1.1
• IANA: Example domains