Le autorità di certificazione sono una delle pietre miliari più importanti per la sicurezza di Internet. Un’autorità di certificazione è qualcuno di cui tutti si fidano, all’inizio, quando nessuno si fida di nessun altro. È quindi compito di questa autorità di certificazione (nota come CA) assicurare che la fiducia sia stabilita tra server e clienti prima che essi stabiliscano una comunicazione su Internet. Una CA è importante non solo per HTTPS usato dai browser e dalle applicazioni web, ma anche per le e-mail criptate, gli aggiornamenti software firmati, le VPN e molto altro ancora. Prenderemo l’esempio prototipico di HTTPS e impareremo la CA, in questo particolare contesto. Anche se è possibile estrapolare il risultato a qualsiasi altra suite di software.

Internet è un canale di comunicazione non fidato. Quando inviate o ricevete informazioni da un vecchio sito HTTP http://www.example.com nel vostro browser, molte cose possono accadere a metà dei vostri pacchetti.

1. Un cattivo attore può intercettare la comunicazione, copiare i dati per se stesso, prima di reinviarli nuovamente sul canale verso di voi o il server con cui stavate parlando. All’insaputa di entrambe le parti, l’informazione è compromessa. Dobbiamo assicurarci che la comunicazione sia privata.
2. Un cattivo attore può modificare le informazioni mentre vengono inviate sul canale. Bob potrebbe aver inviato un messaggio “x” ma Alice riceverebbe “y” da Bob, perché un attore cattivo ha intercettato il messaggio e lo ha modificato. In altre parole, l’integrità del messaggio è compromessa.
3. Infine, e più importante, dobbiamo assicurarci che la persona con cui stiamo parlando sia davvero chi dice di essere. Tornando al dominio example.com. Come possiamo essere sicuri che il server che ci ha risposto sia effettivamente il legittimo proprietario di www.example.com? In qualsiasi punto della rete, si può essere indirizzati erroneamente verso un altro server. Un DNS da qualche parte è responsabile della conversione di un nome di dominio, come www.example.com, in un indirizzo IP sull’internet pubblico. Ma il vostro browser non ha modo di verificare che il DNS abbia tradotto l’indirizzo IP.

I primi due problemi possono essere risolti criptando il messaggio prima che sia inviato su Internet al server. Vale a dire, passando a HTTPS. Tuttavia, l’ultimo problema, quello dell’identità, è dove entra in gioco un’autorità di certificazione.

Iniziare sessioni HTTP crittografate

Il problema principale della comunicazione crittografata su un canale insicuro è “Come si inizia?”

Il primo passo coinvolgerebbe le due parti, il vostro browser e il server, per scambiarsi le chiavi di crittografia da scambiare sul canale insicuro. Se non avete familiarità con il termine chiavi, pensatele come una lunghissima password generata a caso con cui i vostri dati saranno criptati prima di essere inviati sul canale insicuro.

Bene, se le chiavi vengono inviate su un canale insicuro, chiunque può ascoltarle e compromettere la sicurezza della vostra sessione HTTPS in futuro. Inoltre, come possiamo fidarci che la chiave inviata da un server che dichiara di essere www.example.com sia effettivamente il proprietario di quel nome di dominio? Possiamo avere una comunicazione criptata con una parte maligna mascherata da un sito legittimo e non sapere la differenza.

Quindi, il problema di garantire l’identità è importante se vogliamo assicurare uno scambio di chiavi sicuro.

Autorità di certificazione

Potresti aver sentito parlare di LetsEncrypt, DigiCert, Comodo e alcuni altri servizi che offrono certificati TLS per il tuo nome di dominio. Potete scegliere quello che si adatta alle vostre esigenze. Ora, la persona/organizzazione che possiede il dominio deve dimostrare in qualche modo alla sua Autorità di Certificazione di avere effettivamente il controllo sul dominio. Questo può essere fatto o creando un record DNS con un valore unico, come richiesto dall’Autorità di Certificazione, o si può aggiungere un file al proprio server web, con contenuti specificati dall’Autorità di Certificazione, la CA può quindi leggere questo file e confermare che si è un valido proprietario del dominio.

Allora si negozia un certificato TLS con la CA, e questo risulta in una chiave privata e un certificato TLS pubblico emesso per il proprio dominio. I messaggi cifrati dalla vostra chiave privata possono essere decifrati dal certificato pubblico e viceversa. Questo è noto come crittografia asimmetrica

I browser client, come Firefox e Chrome (a volte anche il sistema operativo) hanno la conoscenza delle Autorità di Certificazione. Questa informazione è inserita nel browser/dispositivo fin dall’inizio (cioè, quando vengono installati) in modo da sapere che possono fidarsi di certe CA. Ora, quando provano a connettersi a www.example.com su HTTPS e vedono un certificato rilasciato da, diciamo, DigiCert, il browser può effettivamente verificarlo usando le chiavi memorizzate localmente. In realtà, ci sono alcuni altri passi intermedi, ma questa è una buona panoramica semplificata di ciò che accade.

Ora che il certificato fornito da www.example.com può essere attendibile, questo viene utilizzato per negoziare una chiave di crittografia simmetrica unica che viene utilizzata tra il client e il server per il resto della loro sessione. Nella crittografia simmetrica, una chiave è usata per criptare e decriptare e di solito è molto più veloce della sua controparte asimmetrica.

Nuances

Se l’idea di TLS e della sicurezza di Internet ti attrae, puoi approfondire l’argomento scavando in LetsEncrypt e nella loro TLS CA gratuita. C’è molto più minuzioso in tutta questa trafila di quanto detto sopra.