Quando un indirizzo web inizia con “https” anzich\u00e9 con “http”, la connessione tra il browser e il sito \u00e8 protetta. La “s” finale sta per “secure”, e la protezione \u00e8 fornita da un protocollo chiamato TLS (Transport Layer Security), evoluzione del pi\u00f9 datato SSL, nome che per abitudine si sente ancora usare. HTTPS, in sostanza, \u00e8 il normale protocollo del web (HTTP) fatto passare dentro un canale cifrato da TLS.<\/p>\n
L’obiettivo \u00e8 semplice da enunciare ma fondamentale: fare in modo che ci\u00f2 che si invia e si riceve da un sito non possa essere letto n\u00e9 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.<\/p>\n
TLS lavora su tre fronti contemporaneamente, e tenerli distinti aiuta a capire cosa il protocollo protegge e cosa no.<\/p>\n
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\u00f2 che si trasmette, dalle credenziali ai messaggi ai dettagli di pagamento.<\/p>\n
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<\/a>.<\/p>\n TLS permette al browser di verificare l’identit\u00e0 del sito a cui si connette, attraverso un certificato. \u00c8 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n Un aspetto importante delle versioni moderne del protocollo \u00e8 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\u00e9 quelle chiavi di sessione non esistono pi\u00f9.<\/p>\n L’autenticazione del sito si regge sui certificati digitali. Un certificato \u00e8 un documento elettronico che lega un nome di dominio a una chiave crittografica, ed \u00e8 firmato da un’entit\u00e0 di cui il browser si fida: un’autorit\u00e0 di certificazione (Certificate Authority, o CA).<\/p>\n Il meccanismo funziona cos\u00ec. Il browser e il sistema operativo includono un elenco di autorit\u00e0 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\u00e0 e che il dominio indicato corrisponda a quello che si sta visitando. Se la firma \u00e8 valida e il dominio coincide, il browser accetta il certificato; altrimenti mostra un avviso di sicurezza.<\/p>\n 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\u00e0 del certificato dipende quindi dalla solidit\u00e0 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. \u00c8 esattamente questo il motivo per cui gli algoritmi hash deboli sono stati dismessi dall’ecosistema dei certificati, tema approfondito nella sezione sulla crittografia<\/a>.<\/p>\n 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.<\/p>\n L’icona a forma di lucchetto nella barra degli indirizzi indica una cosa precisa: la connessione \u00e8 cifrata e il certificato del sito \u00e8 valido. Non significa, per\u00f2, che il sito sia onesto o legittimo nei contenuti.<\/p>\n Questa distinzione \u00e8 spesso fraintesa. Anche un sito truffaldino pu\u00f2 ottenere un certificato valido e mostrare il lucchetto, perch\u00e9 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\u00e9 che dietro vi sia un’attivit\u00e0 onesta.<\/p>\n In pratica, il lucchetto va letto cos\u00ec: “la connessione con questo indirizzo \u00e8 protetta”, non “questo sito \u00e8 degno di fiducia”. La verifica dell’identit\u00e0 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<\/a>.<\/p>\n TLS protegge la comunicazione tra il browser e il server, ma non va oltre. Conoscerne i confini evita un falso senso di sicurezza.<\/p>\n 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\u00e0 stati consegnati a destinazione. \u00c8 per questo che le violazioni di dati<\/a> avvengono nonostante l’uso diffuso di HTTPS.<\/p>\n In secondo luogo, TLS autentica il dominio, non l’intenzione. Come detto, un sito malevolo pu\u00f2 avere un certificato perfettamente valido. La cifratura impedisce a un terzo di interferire, ma se \u00e8 la controparte stessa a essere fraudolenta, TLS non pu\u00f2 accorgersene.<\/p>\n 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\u00e9 il problema non \u00e8 il canale ma ci\u00f2 che accade alle sue estremit\u00e0. La cifratura del trasporto \u00e8 una condizione necessaria della sicurezza online, non sufficiente da sola.<\/p>\n HTTPS e TLS rendono il web utilizzabile in modo sicuro: cifrano la comunicazione, ne garantiscono l’integrit\u00e0 e autenticano il sito tramite certificati firmati da autorit\u00e0 di certificazione, che a loro volta poggiano su funzioni hash crittografiche. Il lucchetto conferma che la connessione \u00e8 protetta e che si sta parlando con il dominio indicato, ma non certifica l’onest\u00e0 di chi sta dietro a quel dominio. TLS protegge il viaggio dei dati, non la loro custodia a destinazione n\u00e9 la buona fede della controparte: per questo va affiancato dalle altre difese descritte in questa sezione.<\/p>\nAutenticazione<\/h3>\n
Come si stabilisce una connessione sicura<\/h2>\n
Certificati e autorit\u00e0 di certificazione<\/h2>\n
Che cosa significa davvero il lucchetto<\/h2>\n
I limiti di TLS<\/h2>\n
In sintesi<\/h2>\n