Che cosa significano HTTPS e TLS
Quando un indirizzo web inizia con “https” anziché con “http”, la connessione tra il browser e il sito è protetta. La “s” finale sta per “secure”, e la protezione è fornita da un protocollo chiamato TLS (Transport Layer Security), evoluzione del più datato SSL, nome che per abitudine si sente ancora usare. HTTPS, in sostanza, è il normale protocollo del web (HTTP) fatto passare dentro un canale cifrato da TLS.
L’obiettivo è semplice da enunciare ma fondamentale: fare in modo che ciò che si invia e si riceve da un sito non possa essere letto né alterato da chi si trova nel mezzo della comunicazione, e al tempo stesso garantire di stare parlando davvero con il sito giusto e non con un impostore. Senza queste garanzie, ogni rete pubblica (il Wi-Fi di un bar, di un aeroporto, di un hotel) sarebbe un luogo in cui chiunque potrebbe leggere password e dati altrui.
Le tre protezioni offerte da TLS
TLS lavora su tre fronti contemporaneamente, e tenerli distinti aiuta a capire cosa il protocollo protegge e cosa no.
Riservatezza
I dati scambiati vengono cifrati. Chi intercetta il traffico vede solo una sequenza incomprensibile, non il contenuto reale. Questo impedisce a un intermediario di leggere ciò che si trasmette, dalle credenziali ai messaggi ai dettagli di pagamento.
Integrità
TLS verifica che i dati non siano stati modificati durante il transito. Se un attaccante tentasse di alterare anche un solo frammento della comunicazione, la manomissione verrebbe rilevata e la connessione interrotta. Questa garanzia si appoggia a funzioni crittografiche di verifica, parenti delle funzioni hash trattate nella sezione sulla crittografia.
Autenticazione
TLS permette al browser di verificare l’identità del sito a cui si connette, attraverso un certificato. È la garanzia che, scrivendo l’indirizzo di una banca, si stia davvero parlando con i server di quella banca e non con un sito clonato che si finge tale. Senza autenticazione, la sola cifratura sarebbe poco utile: si potrebbe parlare in modo riservato con l’interlocutore sbagliato.
Come si stabilisce una connessione sicura
Quando il browser apre una pagina in HTTPS, prima ancora di scambiare contenuti avviene una fase di negoziazione, chiamata handshake. In quei pochi istanti accadono diverse cose.
Il browser e il server si accordano sugli algoritmi da usare. Il server presenta il proprio certificato, che il browser verifica (vedremo tra poco come). Le due parti generano quindi un insieme di chiavi segrete condivise, valide solo per quella sessione, usando tecniche di scambio delle chiavi che permettono di concordare un segreto comune senza mai trasmetterlo in chiaro sulla rete. Da quel momento tutto il traffico viene cifrato con quelle chiavi.
Un aspetto importante delle versioni moderne del protocollo è la cosiddetta segretezza in avanti (forward secrecy). Le chiavi di sessione sono temporanee e vengono scartate al termine della comunicazione. Questo significa che, anche se in futuro qualcuno riuscisse a ottenere la chiave privata del server, non potrebbe usarla per decifrare il traffico registrato in passato, perché quelle chiavi di sessione non esistono più.
Certificati e autorità di certificazione
L’autenticazione del sito si regge sui certificati digitali. Un certificato è un documento elettronico che lega un nome di dominio a una chiave crittografica, ed è firmato da un’entità di cui il browser si fida: un’autorità di certificazione (Certificate Authority, o CA).
Il meccanismo funziona così. Il browser e il sistema operativo includono un elenco di autorità di certificazione considerate affidabili, con le rispettive chiavi pubbliche. Quando un sito presenta il proprio certificato, il browser controlla che sia stato firmato da una di queste autorità e che il dominio indicato corrisponda a quello che si sta visitando. Se la firma è valida e il dominio coincide, il browser accetta il certificato; altrimenti mostra un avviso di sicurezza.
Qui entra in gioco la crittografia in modo diretto. La firma di un certificato non viene calcolata sull’intero documento, ma sulla sua impronta prodotta da una funzione hash. La validità del certificato dipende quindi dalla solidità della funzione hash impiegata: se quella funzione fosse vulnerabile, un attaccante potrebbe in teoria costruire un certificato falso con la stessa impronta di uno legittimo, e farlo passare per autentico. È esattamente questo il motivo per cui gli algoritmi hash deboli sono stati dismessi dall’ecosistema dei certificati, tema approfondito nella sezione sulla crittografia.
I certificati hanno inoltre una scadenza e possono essere revocati prima del termine, ad esempio se la chiave privata associata viene compromessa. I browser tengono conto sia della scadenza sia dello stato di revoca quando decidono se fidarsi.
Che cosa significa davvero il lucchetto
L’icona a forma di lucchetto nella barra degli indirizzi indica una cosa precisa: la connessione è cifrata e il certificato del sito è valido. Non significa, però, che il sito sia onesto o legittimo nei contenuti.
Questa distinzione è spesso fraintesa. Anche un sito truffaldino può ottenere un certificato valido e mostrare il lucchetto, perché ottenere un certificato di base richiede solo di dimostrare il controllo del dominio, non di essere un’azienda affidabile. Il lucchetto garantisce che nessuno stia intercettando o alterando la comunicazione con quel sito, e che il sito sia davvero quello indicato dal dominio. Non garantisce che quel dominio appartenga a chi si crede, né che dietro vi sia un’attività onesta.
In pratica, il lucchetto va letto così: “la connessione con questo indirizzo è protetta”, non “questo sito è degno di fiducia”. La verifica dell’identità reale dietro il dominio resta compito dell’utente, soprattutto di fronte a indirizzi simili a quelli legittimi ma non identici, una tattica tipica del phishing.
I limiti di TLS
TLS protegge la comunicazione tra il browser e il server, ma non va oltre. Conoscerne i confini evita un falso senso di sicurezza.
In primo luogo, TLS protegge i dati in transito, non i dati a riposo. Una volta che le informazioni arrivano sul server, sono il server e la sua organizzazione a doverle custodire. Se quel server viene violato, la cifratura del trasporto non offre alcuna protezione: i dati sono già stati consegnati a destinazione. È per questo che le violazioni di dati avvengono nonostante l’uso diffuso di HTTPS.
In secondo luogo, TLS autentica il dominio, non l’intenzione. Come detto, un sito malevolo può avere un certificato perfettamente valido. La cifratura impedisce a un terzo di interferire, ma se è la controparte stessa a essere fraudolenta, TLS non può accorgersene.
Infine, TLS non protegge dagli attacchi che colpiscono gli estremi della comunicazione: un dispositivo infettato da software malevolo, un browser compromesso o un utente indotto con l’inganno a digitare i propri dati su un sito falso restano vulnerabili, perché il problema non è il canale ma ciò che accade alle sue estremità. La cifratura del trasporto è una condizione necessaria della sicurezza online, non sufficiente da sola.
In sintesi
HTTPS e TLS rendono il web utilizzabile in modo sicuro: cifrano la comunicazione, ne garantiscono l’integrità e autenticano il sito tramite certificati firmati da autorità di certificazione, che a loro volta poggiano su funzioni hash crittografiche. Il lucchetto conferma che la connessione è protetta e che si sta parlando con il dominio indicato, ma non certifica l’onestà di chi sta dietro a quel dominio. TLS protegge il viaggio dei dati, non la loro custodia a destinazione né la buona fede della controparte: per questo va affiancato dalle altre difese descritte in questa sezione.
