Il protocollo HTTPS

Nascondi

Quella che segue è una trascrizione automatica dell'episodio.

Pensieri in codice, idee dal mondo del software a cura di Valerio Galano. Salve a tutti e ben ritrovati su Pensieri in codice. Nell’episodio di oggi torniamo a parlare di Web e in particolare di come funzionano alcune parti del Web e ancora più in particolare in questo episodio parleremo del protocollo HTTPS. Molto probabilmente in percentuale sono pochi gli utenti del Web che lo hanno sentito nominare e ancora meno quelli che fanno caso alla sua presenza. Ma questo protocollo è proprio quello che ci permette di svolgere in sicurezza tutte quelle operazioni che sono ormai entrate a far parte della nostra routine giornaliera. Dalle operazioni bancarie, ai accessi alle aree riservate, la consultazione dell’email, il caricamento di file nel cloud, gli acquisti online e tanto altro. In pratica stiamo sfruttando il protocollo HTTPS ogni volta che visitiamo quei siti che il nostro browser definisce sicuri o per i quali ci mostra un piccolo lucchetto verde in alto vicino alla barra dell’indirizzo. Prima però di tuffarci nell’argomento di oggi avrei una piccola richiesta da farvi. Come probabilmente già sapete, ne ho già parlato in un vecchio episodio, sto cercando di farmi confermare la cosiddetta Affiliazione Amazon. Si tratta di un programma di affiliazione grazie al quale posso condividere dei link utilizzando i miei contenuti social e i eventuali acquisti fatti dagli utenti attraverso quei link generano senza caricare sul prezzo per l’acquirente un piccolo profitto per il creatore di contenuti, cioè me, che utilizzo questi, chiamiamoli, fondi per acquistare materiale per il podcast. Ora, se avete ascoltato quel vecchio episodio sapete già che per un podcaster non è così semplice farsi confermare l’affiliazione in quanto quasi tutte le piattaforme di podcasting non sono contemplate da Amazon e l’unica su cui posso effettivamente contare è YouTube, che poi non è esattamente una piattaforma di podcast, ma lasciamo stare. Detto questo, il mio problema è che Amazon mi ha chiuso di nuovo l’affiliazione per la decima o undicesima volta. Quindi, poiché vorrei evitare che me la chiudessero di nuovo semplicemente perché riaprirla e riaggiornare tutti i link comincia a diventare una perdita di tempo notevole, la mia richiesta è, oltre ovviamente a diffondere il più possibile il podcast, quella di iscrivervi, se potete, al canale YouTube di Pensieri in Codice. Questo perché, una volta raggiunti i 500 iscritti, in teoria Amazon dovrebbe verificare e confermare questa affiliazione. A quel punto avrò qualche risorsa in più sia economica sia di tempo, diciamo così, da dedicare alla produzione dei contenuti. Se potete ve ne sarei grato, trovate il link in descrizione. Ora però bando alle ciance e iniziamo con l’argomento di oggi. L’argomento di oggi Lo abbiamo già detto un sacco di volte, quando navighiamo sul web le informazioni che inviamo e che riceviamo da un sito non vanno direttamente dal nostro computer al sito e viceversa, ma sia all’andata che al ritorno passano attraverso tutta una serie di sistemi intermedi che vengono definiti nodi. Ognuno di questi nodi vede quindi passare le nostre informazioni e chi può avere accesso ad uno di questi nodi, non importa se in modo legale o meno, quindi non importa se l’amministratore legittimo del nodo o un hacker che è riuscito a prenderne il controllo, potrebbe sia tentare di leggere le nostre informazioni da e verso il sito web, sia tentare addirittura di manipolarle per ottenere un qualche tipo di vantaggio. Immaginate ad esempio che stiate effettuando un acquisto su un sito di e-commerce. Avete riempito il vostro carrello, siete arrivati alla cassa e state inserendo le informazioni della vostra carta di credito per pagare. Se un nodo intermedio alla comunicazione potesse avere accesso a questi dati della vostra carta di credito, nulla gli impedirebbe di effettuare una serie di transazioni e svuotarvi il conto in banca. Allora voi potreste dire bene, nessun problema, pago il mio ordine con un bonifico. A quel punto, selezionando l’opzione bonifico sul sito che state visitando, sarà il sito stesso a mandarvi il proprio IBAN in modo che voi possiate pagare. E se un nodo intermedio potesse leggere questo IBAN e cambiarlo durante il transito e farvi arrivare un altro IBAN, magari il proprio, so che sembrano due scenari impossibili, ma in realtà sono impossibili proprio grazie al protocollo HTTPS. La comunicazione attraverso tale protocollo, che vi ricordo si verifica semplicemente controllando che il browser indichi il sito come sicuro, garantisce ben 3 vantaggi rispetto ad una comunicazione non sicura tramite il normale protocollo HTTP. Il primo di questi vantaggi è proprio la privacy. Il protocollo HTTPS utilizza infatti un algoritmo di criptografia per cifrare la comunicazione tra il nostro browser ed il sito web. In questo modo, qualsiasi nodo intermedio, nonostante continui a vedere passare il nostro traffico, non avendo le chiavi criptografiche non potrà decifrare nessuna delle informazioni che vedrà passare e ciò renderà di fatto inutili i tentativi di intercettare le comunicazioni. Allo stesso modo, il protocollo HTTPS garantisce anche l’integrità dei dati e questo sempre grazie alla criptografia. Difatti, non potendo interpretare le informazioni che transitano, nessun nodo sarà in grado di modificarle in nessun modo e se dovesse provarci queste non sarebbero più decifrabili dal nostro browser o dal sito web rendendo di fatto inutile questo tentativo di attacco che per inciso prende il nome di Attacco Man in the Middle. In terzo luogo, questo protocollo permette anche di identificare in modo univoco destinatario e emittente della comunicazione e ciò avviene grazie all’utilizzo dei cosiddetti certificati SSL. Questi certificati sono sostanzialmente delle chiavi criptografiche che vengono rilasciate da delle autorità preposte e che vengono poi utilizzati dai browser e dai web server per aggiungere una firma digitale ai messaggi inviati. In tal modo, chiunque riceva un messaggio grazie a tale firma può verificare che esso sia stato effettivamente inviato da quel particolare emittente. Abbiamo dunque visto cosa è in grado di fare il protocollo HTTPS. Ora, in questo blocco, proviamo a capire quale tecniche sono state utilizzate per ottenere questi risultati. Di criptografia abbiamo già parlato più volte su Pensieri in Codice. Vi lascio in descrizione un po’ di link a vecchi episodi mentre per chi vuole un po’ di ricerca teniamo a mente solo un paio di nozioni e cioè che criptografare un messaggio significa prendere questo messaggio e modificarlo utilizzando un algoritmo e una cosiddetta chiave che di solito è una stringa di testo. L’algoritmo è solitamente qualcosa di standard, di condiviso tra tutti quelli che devono essere utilizzati. Nel caso del web si parla di protocollo TLS. Per quanto riguarda la chiave, invece, questa è conosciuta solamente dal mittente e dal destinatario della comunicazione. Questo perché, anche se tutti sanno in che modo è stato criptografato il messaggio, la chiave non è stata utilizzata. La chiave è stata utilizzata solo per il messaggio. Anche se tutti sanno in che modo è stato criptografato il messaggio, solamente mittente e destinatario devono essere in grado di poterlo decifrare. Descritta in questo modo sembra tutto molto semplice. Il mio browser, quando comunica ad esempio con Amazon, utilizzerà una chiave per criptare e decriptare i messaggi. Quando invece comunica con eBay, utilizzerà una chiave diversa. Così il computer di Antonio, quando comunica con Amazon, userà ancora un’altra chiave e un’altra con eBay e così via. Tutte chiavi diverse fra loro, tutte comunicazioni criptografate diversamente. C’è solo un piccolo problema in questo scenario ed è al tempo zero, diciamo così. Cioè quando ancora il browser ed il sito web non hanno preso accordi sulla chiave da utilizzare. Cioè la prima volta che un browser si collega ad un sito web e deve instaurare in qualche modo una comunicazione protetta, dovrà concordare con il sito una chiave da utilizzare. E se la comunicazione non è ancora protetta, occorre un metodo per prendere accordi sulla chiave o in realtà sulle chiavi da utilizzare, facendo in modo però che nessuno dei nodi in ascolto possa carpire tale chiave, altrimenti sarebbe anch’esso in grado di decifrare i nostri messaggi. E per fare ciò viene utilizzato un algoritmo che io ritengo geniale e che prende il nome di criptografia asimmetrica. Lo abbiamo già descritto abbastanza in dettaglio in un altro episodio che vi lascio in descrizione. Però il succo del discorso è che nella criptografia asimmetrica si utilizzano due chiavi. Una, la chiave pubblica, viene utilizzata per cifrare i messaggi. Un’altra, la chiave privata, viene invece utilizzata per decifrarli. La chiave pubblica è appunto pubblica e può essere data a tutti coloro che devono comunicare con uno specifico destinatario. La chiave privata invece è in possesso del solo destinatario, quindi in pratica chiunque è in grado di cifrare dei messaggi al fine di mandarli a quello specifico destinatario, ma solo quel destinatario sarà in grado di leggerli. In ultimo, è interessante capire anche come viene sfruttato il certificato nel protocollo HTTPS. In effetti, i certificati sono proprio le chiavi di criptografia e pertanto si compongono di una chiave pubblica e una chiave privata, che poi in realtà non sono altro che due stringhe di testo. La cosa interessante però è che i certificati vengono anche utilizzati, come abbiamo detto prima, per verificare l’identità del sito con il quale si sta interagendo. Questa identificazione avviene per mezzo di un meccanismo che viene definito catena di fiducia. Ogni certificato infatti viene rilasciato da un ente certificatore, una Certificate Authority, fra le più conosciute ci sono Symantec, Let’s Encrypt, GoDaddy, Comodo. E in pratica queste organizzazioni si occupano sia di generare i vari certificati dei vari domini dei siti web, sia di permettere ai nostri browser di riconoscere che quel determinato certificato che gli è stato inviato appartiene effettivamente a quel determinato sito web. Ora, il processo funziona più o meno in questo modo. Le Certification Authorities hanno dei particolari certificati che vengono definiti Root Certificates, cioè certificati radice. Utilizzando questi certificati generano altri certificati e li assegnano ai siti web e ai domini che ne fanno richiesta. In questo modo, quando i nostri browser si connettono ad un sito web utilizzato da un’altra organizzazione, quando i nostri browser si connettono ad un sito web utilizzando il protocollo HTTPS, ne scaricano il certificato e verificano che questo sia o meno un certificato radice. Se, come nella maggior parte dei casi, il certificato di un sito web non è un certificato radice, allora scarica il certificato intermedio grazie al quale è stato firmato il certificato del sito web. Se anche questo non è un certificato radice, di nuovo scarica il certificato usato per firmare il certificato intermedio e così via, finché ad un certo punto, risalendo la catena delle firme dei certificati, raggiungerà un certificato radice. A quel punto, e solo a quel punto, il nostro browser potrà essere sicuro che il certificato è autentico e ci mostrerà il sito web che stiamo visitando come sicuro. Ovviamente, se questa catena di fiducia dovesse interrompersi o non dovesse mai portare ad un certificato radice, beh, allora il sito verrà contrassegnato come pericoloso. Bene, anche oggi siamo giunti al termine dell’episodio. Io spero di aver descritto questi concetti che in realtà sono molto complicati nel modo più chiaro possibile. In ogni caso, vi lascio in descrizione un po’ di materiale che potete recuperarvi. Per oggi quindi è proprio tutto, voi fate tutte quelle cose che devono fare gli ascoltatori di podcast, commentate, mettete like, iscrivetevi, eccetera, eccetera, eccetera, e non dimenticate che un informatico risolve problemi, a volte anche usando il computer.

Nascondi