HTTPS: come funziona?


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:

  1. Il browser apre la connessione verso un server sul canale HTTPS, porta 443/TCP
  2. Se il browser ottiene una risposta, chiede al server di identificarsi e fornisce un numero casuale (Kc)
  3. Il server fornisce come credenziali il proprio certificato, che include la chiave pubblica, e un proprio numero casuale (Ks)
  4. Il browser esamina il certificato e lo verifica online con le CA che gli sono note
  5. 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
  6. 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
  7. Il browser verifica il MS e attiva la sessione cifrata con un algoritmo simmetrico usando come chiave il MS.
  8. La sessione cifrata con un algoritmo simmetrico ha inizio.
  9. 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.

,

23 risposte a “HTTPS: come funziona?”

  1. Ciao e grazie per questo bel sito (ci torno spesso e volentieri). Pongo una domanda. Quest’estate è passata la notizia che l’SSL era stato bucato. (in realtà da quel che ho capito ci sono solo alcuni casi in cui c’è pericolo che la comunicazione protetta sia decrittabile da un terzo che la intercettasse).
    I comuni mortali hanno un qualche modo per capire se i protocolli usati dal sito internet che si sta visitando in https sono soggetti a tale attacco?
    ciao e grazie

  2. Grazie!
    Tutto ok fino al punto 5. Ma nel punto 6 il server trasmette “in chiaro” (cioè cifrato con chiave privata) il MS? Che senso ha questo passaggio?

    A questo livello di approfondimento, sembra che entrambe le parti potrebbero generarselo a partire da PMS, Ks e Kc, saltando a piè pari il punto 6. Perché far viaggiare la chiave così? Immagino che sia qui che interviene l’eventuale man-in-the-middle…

    • eh no! Nel punto 6 il server risponde codificando il messaggio con la sua chiave privata, ovvero fa capire al browser che “è veramente lui” e che la comunicazione può partire.

  3. […] Già adesso con l’utente che viene tenuto all’oscuro di tutto chi sviluppa le APP commette degli errori madornali e mette a repentaglio la sicurezza dell’utente (qui e qui due dei tanti esempi che dovrebbero far riflettere sulla validità delle APP paragonate all’uso del browser). Twitter è uno di quelli che ha capito il problema e cerca di limitare i danni che programmatori incapaci potrebbero causare: dal 14 gennaio u.s. le chiamate alle API del sito di microblogging potranno essere fatte solo via HTTPS. […]

  4. I punti 6 e 7 non sono corretti: il MS non viene inviato dal server al browser, bensì viene generato da entrambe le parti distintamente, tramite una Pseudo Random Function, basata sul PMS (scambiato al punto 5 e conosciuto unicamente dal Browser e dal Server), che fa uso delle funzioni di hash MD5 e SHA1.
    Quindi, eseguendo:

    MS = PRF(PMS,”master secret”,Kc+Ks),

    con gli stessi input, come definito nelle specifiche (http://tools.ietf.org/html/rfc2246#section-5), i due ottengono lo stesso risultato, che viene poi utilizzato per generare le chiavi simmetriche, utilizzate successivamente per lo scambio di messaggi con protocollo simmetrico (e per la verifica del’integrità con HMAC).

    • Anche perché che senso ha al punto 3 che il server invii al client il Ks, se poi fa tutto il server? Che se ne fa del Ks il client se non per usarlo per qualcosa come per la creazione della chiave simmetrica?

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *