Come funzionano SSL e le catene di certificati, o Chain of Trust?
Lo spiega Davide Ornaghi, partendo da un caso d’uso che lo ha incuriosito in merito.
Ricordandovi che potete trovare altri interessanti articoli nel numero di Febbraio della rubrica Cosa abbiamo imparato?, vi auguriamo buona lettura.
Il contesto
In crittografia una infrastruttura a chiave pubblica, in inglese Public Key infrastructure (PKI), è un insieme di processi e mezzi tecnologici che consentono a terze parti fidate di verificare e/o farsi garanti dell’identità di un utente.
Le chiavi pubbliche tipicamente assumono la forma di certificati digitali.
Il termine PKI viene usato per indicare sia l’autorità di certificazione (Certification Authority, CA) e i relativi accordi, sia, in senso più esteso, l’uso di algoritmi crittografici a chiave pubblica nelle comunicazioni elettroniche.
La struttura della PKI non riguarda solo la CA, ma anche:
- la Registration Authority, attraverso la quale gli utenti si rivolgono per richiedere la certificazione delle chiavi, identificandosi e fornendo almeno la chiave pubblica e l’indirizzo e-mail.
- il Certificate Server ovvero un servizio di directory accessibile mediante un “operational protocol”, tipicamente LDAP; esso è principalmente una lista di pubblicazione dei certificati e delle liste di certificati revocati e sospesi.
Scenario tipico
La maggior parte delle PKI al livello delle imprese fanno affidamento su catene di certificati per stabilire l’identità delle parti: un certificato viene emesso da un’autorità di certificazione, a sua volta autenticata da un certificato emesso da un’autorità di livello più alto, e così via.
In questo modo si stabilisce una gerarchia di certificati, composta da computer, organizzazioni e pacchetti software diversi.
Le PKI a livello di impresa sono spesso strettamente legate ai servizi di directory dell’azienda, in cui la chiave pubblica di ogni dipendente può essere memorizzata assieme ad altri dettagli personali.
Oggi la principale tecnologia per i sistemi di directory è LDAP e infatti il più comune formato usato per i certificati (X.509) nasce con il predecessore di LDAP, lo standard X.500.
Nel World Wide Web, l’infrastruttura PKI viene utilizzata da SSL/TLS per verificare l’identità delle parti.
Caso d’uso – Autenticazione di un microservizio Java
Davide stava simulando il funzionamento di un microservizio Java, rendendolo sicuro tramite l’installazione di un WSO2 Identity Server che aiuta a gestire le autenticazioni e User Stores in modo flessibile e affidabile.
Qualcosa non è andato bene durante l’invocazione del microservizio dopo aver ottenuto un token valido per l’accesso (si guardi l’immagine in copertina dell’articolo).
L’errore descrive il fallimento da parte del client durante la ricostruzione del percorso di certificati.
Andando a scaricare il certificato dal server in locale per installarlo su Windows, Davide ha notato che era stato distribuito da localhost e firmato sempre da localhost.
Per risolvere il problema è sufficiente settare un Java TrustStore che contenesse il certificato appena visto.
Come funziona davvero la verifica delle identità online tramite protocollo SSL?
Root Certificate, Root Store e Intermediate Store
Quando si naviga su un sito web con HTTPS abilitato, il browser deve permettere o bloccare l’accesso in base al livello di fiducia che gli viene riconosciuto utilizzando il protocollo SSL/TLS.
In pratica il browser riceve un certificato SSL X.509 dal dominio a cui si sta tentando di accedere. Il suo compito è cercare di derivare un altro certificato chiamato Root Certificate, che viene rilasciato da una Certificate Authority (CA).
Ogni browser o sistema operativo possiede degli archivi chiamati Root Store ed Intermediate Store dove vengono salvati tutti i certificati che sono stati già verificati perché rilasciati direttamente da una CA (e quindi affidabili per definizione), o perché sono già stati derivati e verificati nelle derivazioni precedenti.
Chain of trust
Il processo di derivazione di un Root Certificate (immagine seguente) è svolto dal browser con la seguente modalità:
- Ottenere il certificato SSL dal server al quale ci si connette.
- Recuperare dal server l’identificativo della CA che ha distribuito il precedente, ovvero di un certificato intermedio (il quale può trovarsi nello store oppure recuperato dalla CA).
- Dal certificato intermedio ripetere la stessa azione fino a che si ottiene un Root Certificate, riconoscibile in quanto è distribuito e verificato da sé stesso e che deve essere presente nel Root Store del browser.
- Utilizzare la chiave pubblica del Root Certificate per accertarsi che il certificato intermedio precedente sia affidabile, e così via fino a tornare al certificato SSL iniziale.
- Se tutti i certificati sono stati verificati, il client potrà fidarsi che l’identità del server sia quella che il suo certificato dichiara.
Il presupposto per il funzionamento di questo processo è che il Root Certificate e tutti i certificati firmati con la sua chiave privata siano affidabili, e che tutti i certificati della catena non siano scaduti o revocati.
Se la verifica dovesse fallire, il browser dovrebbe mostrare un messaggio di warning e/o salvare in cache i certificati intermedi corretti per uso futuro.
Per esplorare la catena di un dominio da browser Google Chrome:
- Selezionare il lucchetto a sinistra della barra di navigazione.
- Cliccare la voce Certificato.
- Cliccare la sezione Percorso certificazione presente all’interno della finestra Certificato.
Sicurezza Root Certificate
Se la chiave privata di un Root certificate venisse rubata, un attaccante potrebbe fingersi autorità e firmare i propri domini sotto la falsa identità.
Tutti gli utenti, una volta ridiretti al server dell’attaccante, penseranno di stare navigando su un sito web sicuro.
Per rimediare, tutti i certificati rilasciati dalla vera CA dovrebbero essere revocati; un’operazione davvero poco conveniente.
Sicurezza Intermediate Certificate
Per evitare che questo problema avvenga le CA hanno aggiunto uno strato di sicurezza tramite gli Intermediate Certificate.
In questo modo l’utente non visualizza direttamente i certificati firmati dal Root Certificate bensì quelli firmati da un componente intermedio.
Così facendo si delega compito di verifica dell’identità ad un componente meno importante.
Conclusioni
Nel suo caso Davide aveva bisogno di diventare la CA di se stesso aggiungendo il Root Certificate di WSO2 allo store che poi veniva incluso durante l’esecuzione della Java Virtual Machine. In generale è necessario installare sul proprio server una catena di certificati per assicurare all’utente una navigazione sicura (e per avere il lucchetto verde sulla barra di navigazione).