Abbastanza bene, ma non è una bacchetta magica.
Prima di spiegare HTTPS è necessario spiegare cosa sia la Public Key Infrastructure (PKI) e prima ancora la crittografia asimmetrica, il vero mattone con cui è costruito tutto quanto: se qualcuno scoprisse come crackare velocemente una cifratura asimmetrica verrebbe giù tutto o peggio.
I sistemi di crittografia più noti sono simmetrici, ovvero quelli che richiedono una chiave, la stessa, per cifrare e decifrare un testo: dal cifrario di Cesare a Enigma era questo il modo di nascondere le informazioni fino a qualche decennio fa.
La crittografia asimmetrica utilizza un algoritmo che sfrutta una coppia di chiavi: un messaggio cifrato con una chiave può essere decifrato solamente con l’altra chiave della coppia e solo con quella. Questo tipo di algoritmo ha permesso di creare la crittografia a chiave pubblica: quando si genera una coppia di chiavi una viene chiamata chiave privata, l’altra viene chiamata chiave pubblica; la chiave privata deve essere custodita gelosamente dal proprietario, mentre quella pubblica deve essere disseminata il più possibile.
Il metodo a chiave pubblica ha due vantaggi: se io cifro un testo con la mia chiave privata non lo faccio per renderlo segreto, ma per fare in modo che tutti sappiano che l’ho scritto io perché quel messaggio sarà decifrabile solamente con la mia chiave pubblica (nota a tutti). Se una persona mi vuole scrivere un messaggio riservato lo cifrerà con la mia chiave pubblica perché solamente chi è in possesso dell’omologa chiave privata (si presuppone che sia solamente io) può decifrare il messaggio.
Un metodo analogo può essere utilizzato per presentare uno sconosciuto ad un amico. Se io conosco personalmente e mi fido di una persona che ha appena generato una coppia di chiavi e voglio fare in modo che chi si fida della mia chiave si fidi anche di quella del nuovo venuto posso cifrare la chiave pubblica del nuovo arrivato con la mia chiave privata, certificando in questo modo la bontà della chiave pubblica dello sconosciuto, che, a quel punto, diventa conosciuto alla mia rete di contatti.
Ecco creata la cosiddetta rete di fiducia, che sta alla base della PKI. La PKI utilizzata da HTTPS è ti tipo gerarchico: ci sono alcune Certification Authority (CA) di cui i browser si fidano implicitamente in quanto le loro chiavi pubbliche sono distribuite assieme al software medesimo. Questo è il bandolo della matassa per arrivare a fidarsi di un sito.
Il sito che vuole garantire la sua identità nei confronti dei visitatori e vuole che le comunicazioni siano cifrate acquista da una delle CA un certificato firmato da loro. Ci troviamo nella stessa situazione dell’esempio della presentazione dello sconosciuto che ho fatto prima. Quando un browser visita un sito che presenta un certificato, il software risale l’albero delle CA che hanno firmato quel certificato: se la ricerca finisce con una CA nota, il certificato viene dichiarato attendibile, altrimenti l’utente viene avvisato in modo palese del rischio che starebbe per correre.
Abbiamo quindi una PKI basata sulla crittografia asimmetrica, è ora di mettere assieme i pezzi e applicarti ad HTTP per farlo diventare HTTPS. Ecco quello che succede durante i convenevoli iniziali tra browser e server:
- Il browser apre la connessione verso un server sul canale HTTPS, porta 443/TCP
- Se il browser ottiene una risposta, chiede al server di identificarsi e fornisce un numero casuale (Kc)
- Il server fornisce come credenziali il proprio certificato, che include la chiave pubblica, e un proprio numero casuale (Ks)
- Il browser esamina il certificato e lo verifica online con le CA che gli sono note
- Il browser, verificato il certificato, invia un messaggio al server che contiene un altro numero casuale (PMS, pre master secret) cifrato con la chiave pubblica del server
- Il server risponde con il Master Secret (MS), un numero ottenuto elaborando con un algoritmo noto PMS, Kc e Ks cifrati con la sua chiave privata
- Il browser verifica il MS e attiva la sessione cifrata con un algoritmo simmetrico usando come chiave il MS.
- La sessione cifrata con un algoritmo simmetrico ha inizio.
- Alla fine della sessione browser e server distruggono Kc, Ks, PMS e MS.
Ovviamente questa è una versione semplificata del dialogo (handshake) iniziale tra browser e server. Il protocollo descritto qui è analogo a quelli di altri protocolli ‘S’ come IMAPS, POP3S e SMTPS, che sfruttano tutti la Transport Layer Security (ex SSL). Il TLS prevede molte altre funzionalità oltre a quelle descritte, tra cui la possibilità che il browser (client) debba a sua volta presentare un certificato emesso da una CA nota al server.
L’handshake HTTPS avviene in una frazione di secondo, qui è descritto in dettaglio cosa passa sui fili.
È importante notare che la sessione HTTPS vera e propria avviene cifrando i dati con un algoritmo simmetrico che ha come chiave la MS e non con un algoritmo asimmetrico. Il motivo di tutto ciò è la forte richiesta di potenza di elaborazione necessaria per cifrare i dati con un algoritmo asimmetrico.
Lascia un commento