Robert Heaton

HTTPS è semplicemente il tuo protocollo HTTP standard spalmato con un generoso strato di deliziosa bontà di crittografia SSL/TLS. A meno che qualcosa non vada terribilmente storto (e può succedere), impedisce a persone come la famigerata Eve di visualizzare o modificare le richieste che compongono la vostra esperienza di navigazione; è ciò che mantiene le vostre password, comunicazioni e dettagli delle carte di credito al sicuro sul filo tra il vostro computer e i server a cui volete inviare questi dati. Mentre il piccolo lucchetto verde e le lettere “https” nella tua barra degli indirizzi non significano che non ci sia ancora un’ampia corda per te e per il sito web che stai visualizzando per appendervi altrove, ti aiutano almeno a comunicare in modo sicuro mentre lo fai.

Cos’è HTTPS e cosa fa?

HTTPS prende il ben noto e compreso protocollo HTTP e semplicemente vi sovrappone uno strato di crittografia SSL/TLS (di seguito denominato semplicemente “SSL”). I server e i clienti parlano ancora esattamente lo stesso HTTP l’uno con l’altro, ma su una connessione sicura SSL che cripta e decripta le loro richieste e risposte. Il livello SSL ha 2 scopi principali:

• Verificare che stai parlando direttamente con il server con cui pensi di parlare
• Assicurare che solo il server possa leggere ciò che gli mandi e solo tu puoi leggere ciò che lui ti manda indietro

La parte davvero, davvero intelligente è che chiunque può intercettare ogni singolo messaggio che scambi con un server, compresi quelli in cui ti metti d’accordo sulla chiave e sulla strategia di crittografia da usare, e comunque non essere in grado di leggere nessuno dei dati reali che mandi.

Come viene stabilita una connessione SSL

Una connessione SSL tra un client e un server viene stabilita da un handshake, i cui obiettivi sono:

• Per soddisfare il client che sta parlando con il server giusto (e opzionalmente viceversa)
• Perché le parti si siano accordate su una “suite di cifratura”, che include quale algoritmo di crittografia useranno per scambiare dati
• Perché le parti abbiano concordato tutte le chiavi necessarie per questo algoritmo

Una volta stabilita la connessione, entrambe le parti possono usare l’algoritmo e le chiavi concordate per inviarsi messaggi in modo sicuro. Suddivideremo l’handshake in 3 fasi principali – Hello, Certificate Exchange e Key Exchange.

1. Hello – L’handshake inizia con il client che invia un messaggio ClientHello. Questo contiene tutte le informazioni di cui il server ha bisogno per connettersi al client via SSL, comprese le varie suite di cifratura e la versione massima SSL che supporta. Il server risponde con un ServerHello, che contiene informazioni simili richieste dal client, compresa una decisione basata sulle preferenze del client su quale suite di cifratura e quale versione di SSL sarà usata.

2. Scambio di certificati – Ora che il contatto è stato stabilito, il server deve provare la sua identità al client. Questo si ottiene usando il suo certificato SSL, che è un po’ come il suo passaporto. Un certificato SSL contiene vari dati, tra cui il nome del proprietario, la proprietà (ad esempio il dominio) a cui è collegato, la chiave pubblica del certificato, la firma digitale e informazioni sulle date di validità del certificato. Il client verifica che o si fida implicitamente del certificato, o che è verificato e fidato da una delle diverse Autorità di Certificazione (CA) di cui si fida anche implicitamente. Molto di più su questo tra breve. Si noti che il server può anche richiedere un certificato per provare l’identità del client, ma questo accade tipicamente solo in applicazioni molto sensibili.

3. Scambio di chiavi – La crittografia dei dati effettivi dei messaggi scambiati dal client e dal server sarà fatta usando un algoritmo simmetrico, la cui esatta natura è già stata concordata durante la fase di Salve. Un algoritmo simmetrico utilizza una singola chiave sia per la crittografia che per la decrittografia, in contrasto con gli algoritmi asimmetrici che richiedono una coppia di chiavi pubbliche/private. Entrambe le parti devono accordarsi su questa singola chiave simmetrica, un processo che viene realizzato in modo sicuro usando la crittografia asimmetrica e le chiavi pubbliche/private del server.

Il client genera una chiave casuale da usare per l’algoritmo simmetrico principale. La cripta utilizzando un algoritmo concordato anche durante la fase di Salve, e la chiave pubblica del server (che si trova sul suo certificato SSL). Invia questa chiave criptata al server, dove viene decriptata usando la chiave privata del server, e le parti interessanti dell’handshake sono complete. Le parti sono sufficientemente soddisfatte di stare parlando con la persona giusta, e hanno segretamente concordato una chiave per criptare simmetricamente i dati che stanno per inviarsi. Le richieste e le risposte HTTP possono ora essere inviate formando un messaggio in chiaro e poi criptandolo e inviandolo. L’altra parte è l’unica che sa come decifrare questo messaggio, e così gli attaccanti Man In The Middle non sono in grado di leggere o modificare qualsiasi richiesta che possono intercettare.

Certificati

Al suo livello più elementare, un certificato SSL è semplicemente un file di testo, e chiunque abbia un editor di testo può crearne uno. È infatti possibile creare banalmente un certificato che dichiara che siete Google Inc. e che controllate il dominio gmail.com. Se questa fosse l’intera storia, allora SSL sarebbe uno scherzo; la verifica dell’identità sarebbe essenzialmente il cliente che chiede al server “sei Google?”, il server che risponde “ehm, sì, assolutamente, ecco un pezzo di carta con su scritto ‘Io sono Google'” e il cliente che dice “Ok, bene, ecco tutti i miei dati”. La magia che impedisce questa farsa è nella firma digitale, che permette a una parte di verificare che il pezzo di carta di un’altra parte sia davvero legittimo.

Ci sono 2 ragioni ragionevoli per cui ci si può fidare di un certificato:

• Se è su una lista di certificati di cui ci si fida implicitamente
• Se è in grado di dimostrare che si fida del controllore di uno dei certificati della lista di cui sopra

Il primo criterio è facile da verificare. Il tuo browser ha una lista preinstallata di certificati SSL di fiducia delle Autorità di Certificazione (CA) che puoi visualizzare, aggiungere e rimuovere. Questi certificati sono controllati da un gruppo centralizzato di organizzazioni (in teoria, e generalmente in pratica) estremamente sicure, affidabili e degne di fiducia come Symantec, Comodo e GoDaddy. Se un server presenta un certificato da quella lista, allora sai che puoi fidarti di loro.

Il secondo criterio è molto più difficile. È facile per un server dire “ehm sì, il mio nome è ehm, Microsoft, ti fidi di Symantec e ehm, loro si fidano completamente di me, quindi è tutto a posto”. Un cliente un po’ intelligente potrebbe poi andare a chiedere a Symantec “Ho una Microsoft qui che dice che ti fidi di loro, è vero? Ma anche se Symantec dice “sì, li conosciamo, Microsoft è legale”, non si sa ancora se il server che afferma di essere Microsoft è effettivamente Microsoft o qualcosa di molto peggio. È qui che entrano in gioco le firme digitali.

3.2 Firme digitali

Come già notato, i certificati SSL hanno una coppia di chiavi pubbliche/private associate. La chiave pubblica è distribuita come parte del certificato, e la chiave privata è tenuta incredibilmente al sicuro. Questa coppia di chiavi asimmetriche è usata nella stretta di mano SSL per scambiare un’ulteriore chiave per entrambe le parti per criptare e decriptare simmetricamente i dati. Il client usa la chiave pubblica del server per cifrare la chiave simmetrica e inviarla in modo sicuro al server, e il server usa la sua chiave privata per decifrarla. Chiunque può criptare usando la chiave pubblica, ma solo il server può decriptare usando la chiave privata.

Il contrario è vero per una firma digitale. Un certificato può essere “firmato” da un’altra autorità, per cui l’autorità effettivamente dichiara “abbiamo verificato che il controllore di questo certificato controlla anche la proprietà (dominio) elencata nel certificato”. In questo caso l’autorità usa la sua chiave privata per criptare (in senso lato) il contenuto del certificato, e questo testo cifrato viene allegato al certificato come firma digitale. Chiunque può decifrare questa firma usando la chiave pubblica dell’autorità e verificare che il risultato sia il valore decifrato previsto. Ma solo l’autorità può criptare il contenuto usando la chiave privata, e quindi solo l’autorità può effettivamente creare una firma valida in primo luogo.

Quindi se un server arriva sostenendo di avere un certificato per Microsoft.com che è firmato da Symantec (o qualche altra CA), il vostro browser non deve credergli sulla parola. Se è legittimo, Symantec avrà usato la sua chiave privata (ultra segreta) per generare la firma digitale del certificato SSL del server, e quindi il tuo browser può usare la sua chiave pubblica (ultra pubblica) per controllare che questa firma sia valida. Symantec avrà fatto dei passi per assicurarsi che l’organizzazione per cui stanno firmando possiede davvero Microsoft.com, e così, dato che il tuo cliente si fida di Symantec, può essere sicuro che sta davvero parlando con Microsoft Inc.

3.3 Autofirma

Nota che tutti i certificati CA root sono “autofirmati”, il che significa che la firma digitale è generata usando la chiave privata del certificato stesso. Non c’è niente di intrinsecamente speciale nel certificato di una CA radice – puoi generare il tuo certificato autofirmato e usarlo per firmare altri certificati se vuoi. Ma poiché il vostro certificato casuale non è precaricato come CA in nessun browser, nessuno di loro si fiderà di voi per firmare i vostri o altri certificati. State effettivamente dicendo “eh sì, sono totalmente Microsoft, ecco un certificato ufficiale di identità emesso e firmato da me,” e tutti i browser che funzionano correttamente lanceranno un messaggio di errore molto spaventoso in risposta alle vostre dubbie credenziali.

Questo mette un enorme peso su tutti gli editori di browser e sistemi operativi per fidarsi solo delle CA radice pulite, poiché queste sono le organizzazioni di cui i loro utenti si fidano per controllare i siti web e mantenere i certificati sicuri. Questo non è un compito facile.

3.4 Di cosa ti stai fidando?

È interessante notare che il tuo client tecnicamente non sta cercando di verificare se deve fidarsi o meno della parte che gli ha inviato un certificato, ma se deve fidarsi della chiave pubblica contenuta nel certificato. I certificati SSL sono completamente aperti e pubblici, quindi qualsiasi attaccante potrebbe prendere il certificato di Microsoft, intercettare la richiesta di un cliente a Microsoft.com e presentargli il certificato legittimo. Il cliente lo accetterebbe e inizierebbe felicemente la stretta di mano. Tuttavia, quando il client cripta la chiave che sarà usata per la crittografia effettiva dei dati, lo farà usando la vera chiave pubblica di Microsoft da questo certificato reale. Poiché l’attaccante non ha la chiave privata di Microsoft per decifrarla, è bloccato. Anche se l’handshake è completato, non sarà ancora in grado di decifrare la chiave, e quindi non sarà in grado di decifrare nessuno dei dati che il client gli invia. L’ordine è mantenuto finché l’attaccante non controlla la chiave privata di un certificato fidato. Se il cliente viene in qualche modo indotto a fidarsi di un certificato e di una chiave pubblica la cui chiave privata è controllata da un aggressore, iniziano i guai.

4.1 Un bar può monitorare il mio traffico HTTPS sulla sua rete?

No. La magia della crittografia a chiave pubblica significa che un aggressore può guardare ogni singolo byte di dati scambiati tra il tuo client e il server e non avere ancora idea di cosa vi state dicendo al di là di quanti dati vi state scambiando. Tuttavia, il vostro normale traffico HTTP è ancora molto vulnerabile su una rete wi-fi insicura, e un sito web inconsistente può cadere vittima di qualsiasi numero di espedienti che in qualche modo vi ingannano nell’inviare il traffico HTTPS o su HTTP normale o semplicemente nel posto sbagliato completamente. Per esempio, anche se un modulo di login invia una combinazione di nome utente/password su HTTPS, se il modulo stesso viene caricato in modo insicuro su HTTP, allora un aggressore potrebbe intercettare l’HTML del modulo mentre arriva sulla tua macchina e modificarlo per inviare i dettagli di login al proprio endpoint.

4.2 La mia azienda può monitorare il mio traffico HTTPS sulla sua rete?

Se stai anche usando una macchina controllata dalla tua azienda, allora sì. Ricorda che alla radice di ogni catena di fiducia c’è una CA implicitamente fidata, e che una lista di queste autorità è memorizzata nel tuo browser. La vostra azienda potrebbe usare il suo accesso alla vostra macchina per aggiungere il proprio certificato autofirmato a questa lista di CA. Potrebbero quindi intercettare tutte le vostre richieste HTTPS, presentando certificati che affermano di rappresentare il sito web appropriato, firmati dalla loro falsa CA e quindi indiscutibilmente fidati dal vostro browser. Dal momento che cifrereste tutte le vostre richieste HTTPS utilizzando la chiave pubblica del loro certificato sospetto, potrebbero utilizzare la chiave privata corrispondente per decifrare e ispezionare (anche modificare) la vostra richiesta, e poi inviarla al luogo previsto. Probabilmente non lo fanno. Ma potrebbero.

Incidentalmente, questo è anche il modo in cui si usa un proxy per ispezionare e modificare le richieste HTTPS altrimenti inaccessibili fatte da un’app per iPhone.

4.3 Quindi cosa è successo con Lavabit e l’FBI?

Lavabit era il provider di posta elettronica super-sicuro di Edward Snowden durante la follia della fuga di notizie della NSA del 2013. Come abbiamo visto, nessuna quantità di hacking standard potrebbe permettere all’FBI di vedere qualsiasi dato in viaggio tra Lavabit e i suoi clienti. Senza la chiave privata del certificato SSL di Lavabit, l’agenzia era fregata. Tuttavia, un utile giudice degli Stati Uniti ha detto al fondatore di Lavabit, Ladar Levison, che doveva consegnare questa chiave, dando effettivamente all’FBI la libertà di spiare il traffico a suo piacimento. Levison ha fatto un coraggioso tentativo di temporeggiare consegnando la chiave di 2.560 caratteri in 11 pagine cartacee con caratteri a 4 punti, ma è stato colpito da un ordine che gli imponeva di consegnare la chiave in un formato utile o di affrontare una multa di 5.000 dollari al giorno finché non l’avesse fatto.

Una volta ottemperato, GoDaddy, la CA di Lavabit, revocò il certificato, avendolo (correttamente) ritenuto compromesso. Questo ha aggiunto il certificato Lavabit a una Certificate Revocation List (CRL), una lista di certificati screditati di cui i clienti non dovrebbero più fidarsi per fornire una connessione sicura. I certificati compromessi, autofirmati o comunque non degni di fiducia fanno sì che i browser visualizzino un grande messaggio di errore rosso e scoraggino o vietino del tutto ulteriori azioni da parte dell’utente. Sfortunatamente, i browser continueranno a fidarsi di un certificato rotto fino a quando non tireranno gli ultimi aggiornamenti della CRL, un processo che è apparentemente imperfetto nella pratica.

Conclusione

HTTPS non è infrangibile, e il protocollo SSL deve evolversi costantemente mentre vengono scoperti e schiacciati nuovi attacchi contro di esso. Ma è ancora un modo incredibilmente robusto di trasmettere dati segreti senza preoccuparsi di chi vede i vostri messaggi. Ci sono naturalmente molti dettagli di implementazione non menzionati qui, come il formato esatto e l’ordine dei messaggi di handshake, handshake abbreviati per raccogliere le sessioni recenti senza dover rinegoziare le chiavi e le suite di cifratura, e le numerose opzioni di crittografia diverse disponibili in ogni fase. La cosa fondamentale da ricordare è che mentre HTTPS mantiene i dati al sicuro sul filo verso la sua destinazione, non ti protegge in alcun modo (come utente o sviluppatore) contro XSS o perdite di database o qualsiasi altra cosa che va a sbattere di notte. Siate felici che vi copra le spalle, ma rimanete vigili. Nelle parole immortali di Will Smith, “Cammina nell’ombra, muoviti in silenzio, guardati dalla violenza extra-terrestre.”

Se ti è piaciuto questo, probabilmente ti piacerà il mio post che spiega i dettagli della vulnerabilità FREAK del 2015 in SSL.