Il protocollo HTTPS (seconda parte)

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. Quello che state ascoltando è una sorta di episodio integrativo per la puntata della settimana scorsa, la numero 44 sul protocollo HTTPS. Si tratta di una seconda parte non prevista che mi è sembrata necessaria a seguito di una discussione che si è tenuta sul gruppo Telegram di Pensieri in codice. In questa breve discussione uno degli utenti chiedeva alcune delucidazioni su un paio di concetti sui quali forse non mi sono soffermato abbastanza. Prontamente un altro utente ha affugato questi dubbi con un paio di esempi che mi sono sembrati molto interessanti. Dunque, ho pensato di unirli a un altro paio di concetti e realizzare questo episodio. Quindi ringrazio Pacca, questo è il nome dell’utente, per la pronta risposta e per gli esempi che sto per rubargli. Consiglio a voi, nel caso non l’abbiate già fatto, di ascoltare prima l’episodio numero 44 che vi metto in descrizione, altrimenti è difficile che possiate seguire il discorso di questo episodio. Ultima cosa prima di iniziare, grazie a tutti quegli utenti che si sono iscritti al canale YouTube di Pensieri in codice e iniziamo! Il primo concetto su cui dunque vorrei ritornare è quello delle chiavi pubbliche e private. È vero che vi ho parlato di come vengono utilizzate, perché sono necessarie ed è vero anche che vi ho linkato un vecchio episodio nel quale parlavamo in modo approfondito di come vengono generate. Tuttavia, forse non mi sono soffermato abbastanza sul fascino e sulla potenza di questo tipo di algoritmo. Queste chiavi, infatti, possono avere un duplice utilizzo e, in effetti, entrambi questi utilizzi sono parte integrante del protocollo HTTPS. Il primo utilizzo, l’abbiamo detto anche nel scorso episodio, è quello di crittografare le informazioni, ma crittografarle in un modo molto particolare. Nella crittografia asimmetrica, infatti, come faceva anche notare Pacca nel gruppo Telegram, la chiave pubblica può essere considerata come un vero e proprio lucchetto. Metaforicamente parlando, questo lucchetto esiste in infinite copie e può essere distribuito a tutta una serie di attori. Questi attori possono utilizzare questi lucchetti, che hanno ricevuto, sempre metaforicamente parlando, aperti, per chiudere informazioni all’interno di metaforiche scatole. Poiché quelli che sono stati distribuiti sono solo lucchetti, una volta che le informazioni saranno chiuse all’interno di una scatola, nessuno potrà più aprire tale scatola e leggere o modificare tali informazioni. L’unico che avrà questa possibilità sarà colui che è in possesso della chiave che apre tutti questi lucchetti. E, sempre nella nostra metafora, questa chiave è, appunto, la chiave privata. Quando il nostro browser comunica, dunque, con un sito web tramite il protocollo HTTPS, riceve da questo un lucchetto da utilizzare per proteggere le informazioni da inviargli. Siccome il lucchetto ricevuto potrà essere aperto solamente dal sito in questione, noi possiamo essere sicuri che le informazioni spedite saranno protette. Come dicevo però poco fa, questo non è l’unico utilizzo per le chiavi pubblica e privata. Difatti, anche nello scorso episodio abbiamo parlato di certificati e di catena di fiducia. In effetti, anche questo meccanismo funziona grazie alle chiavi ed, in particolare, utilizzandole al contrario. Se, infatti, si utilizza una chiave privata per crittografare un testo o un’informazione, questa potrà essere decrittata grazie all’utilizzo delle chiavi pubbliche. In questo modo è possibile, per gli attori che sono in possesso della chiave pubblica, essere sicuri che un determinato testo sia stato crittografato solo dal soggetto in possesso della chiave privata. Questa operazione di crittografare un testo con la chiave privata è detta proprio firma e si tratta di quella stessa firma grazie alla quale ogni browser è in grado di risalire la catena di verità e verificare di firma in firma che un certificato sia effettivamente autentico. Infine, questo ci porta all’ultimo concetto di cui forse non abbiamo parlato abbastanza o che in realtà abbiamo solo accennato, e cioè il concetto di certificato self-signed. Questo tipo di certificati viene utilizzato soprattutto per lo sviluppo. È, infatti, possibile per chiunque generare un certificato e, a livello tecnico, esso funziona esattamente allo stesso modo di un certificato rilasciato da un certification authority. Tuttavia è gratis e quindi è più adatto allo sviluppo, ai test, eccetera. L’unica cosa che lo distingue da un certificato rilasciato da una certification authority è proprio il fatto di essere stato generato in maniera manuale e non da una chiave privata root o da una sua discendente. Bene, io spero che questo piccolo episodio fuori programma vi abbia fatto piacere. In ogni caso, vi invito sempre a unirvi al gruppo Telegram dove, come potete vedere, si svolgono belle conversazioni e ci sono belle persone, a parte un paio che odiano il PHP. Ma li sopportiamo, che ci volete fare? Detto questo, vi ringrazio di aver ascoltato fin qui, vi do appuntamento al prossimo episodio e vi ricordo che un programmatore risolve i problemi, a volte anche usando il computer.

Nascondi