HPKP: che cos'è il public key pinning per HTTP

La sicurezza dei canali per la tra­smis­sio­ne dei dati è un requisito im­por­tan­te nella co­mu­ni­ca­zio­ne e nel lavoro digitali. Spe­cial­men­te quando si inviano o ricevono pacchetti dati da remoto, o mentre non si è a casa o in ufficio, è fon­da­men­ta­le che l'intero percorso di tra­smis­sio­ne sia protetto: non a caso è prassi comune tra­smet­te­re in­for­ma­zio­ni riservate esclu­si­va­men­te tramite VPN o con­nes­sio­ni SSL/TLS. Enti e aziende ga­ran­ti­sco­no la quasi in­vio­la­bi­li­tà di questi pro­to­col­li at­tra­ver­so i propri server DNS e autorità di cer­ti­fi­ca­zio­ne se­le­zio­na­te. Ma gli utenti che operano al di fuori di queste strutture sono soggetti alle gerarchie delle autorità cer­ti­fi­ca­ti­ve e dei DNS pubblici, il che aumenta la pro­ba­bi­li­tà di un attacco man in the middle ai dati.

La causa prin­ci­pa­le del­l'au­men­to del rischio legato alla sicurezza sono i cer­ti­fi­ca­ti falsi emessi da autorità di cer­ti­fi­ca­zio­ne dubbie o in­fil­tra­te. Pa­ra­dos­sal­men­te questo significa che la sicurezza della con­nes­sio­ne e dei dati potrebbe essere messa a re­pen­ta­glio proprio da chi dovrebbe ga­ran­tir­la. Nel 2011 Google ha in­tro­dot­to le co­sid­det­te HTTP Public Key Pinning (HPKP), uno standard spe­ci­fi­ca­to nella RFC 7469.

Il Public Key Pinning è un'e­sten­sio­ne del pro­to­col­lo HTTP (Hypertext Transfer Protocol) che consente di spe­ci­fi­ca­re il set di chiavi pubbliche per le future con­nes­sio­ni SSL/TLS a un host. In questo modo un client apprende al primo tentativo di contatto quali sono le chiavi pubbliche sicure per con­net­ter­si a un de­ter­mi­na­to host. Si parla in questo senso di modello Trust on First Use (fiducia al primo utilizzo). Ogni voce di una chiave ve­ri­fi­ca­ta viene chiamata pin, da cui il mec­ca­ni­smo prende il nome. Tutti i pin creati vengono trasmessi al client tramite l'header HTTP e quindi me­mo­riz­za­ti per un de­ter­mi­na­to periodo.

Al momento di ef­fet­tua­re una nuova richiesta di con­nes­sio­ne, il client verifica se la catena di cer­ti­fi­ca­zio­ne per la tra­smis­sio­ne SSL/TLS contiene una chiave pubblica pre­ce­den­te­men­te ricevuta tramite HPKP. In caso negativo, ad esempio nella cir­co­stan­za di un cer­ti­fi­ca­to falso, viene vi­sua­liz­za­to un messaggio di errore e la con­nes­sio­ne non viene stabilita. Questo processo di verifica si chiama anche convalida del pin. Le voci dei pin nell'header HTTP hanno gros­so­mo­do questo aspetto:

Questo esempio mostra tutte le quattro direttive che possono essere contenute da un pin nel­l'hea­der HTTP:

• pin: la direttiva pin è la parte più im­por­tan­te del­l'i­scri­zio­ne. È co­sti­tui­ta da un nome e da un valore: il nome fornisce in­for­ma­zio­ni sul­l'al­go­rit­mo uti­liz­za­to per la crit­to­gra­fia – finora soltanto SHA256; il valore hash compreso tra le vir­go­let­te è una stringa co­di­fi­ca­ta in Base64, nota anche come fin­ger­print. Per ogni chiave (inclusi i back-up), ogni pin deve avere una direttiva separata.
   
• max-age: la direttiva max-age specifica in secondi il tempo durante il quale il pin è valido, co­mu­ni­can­do al cliente quanto a lungo possa valutare sicura un'ec­cel­len­te chiave pubblica. Nel­l'e­sem­pio uti­liz­za­to i pin listati vengono can­cel­la­ti dopo 30 giorni (2.592.000 secondi).
   
• in­clu­de­Sub­Do­mains: l'in­di­ca­zio­ne in­clu­de­Sub­Do­mains è opzionale e non richiede un valore. La sua funzione è di segnalare al client che le regole di cer­ti­fi­ca­zio­ne spe­ci­fi­ca­te non valgono solo per il dominio, ma anche per tutti i sot­to­do­mi­ni che ap­par­ten­go­no all'host.
   
• report-uri: se la direttiva report-uri è attivata, tutti i tentativi di convalida del pin non riusciti vengono inviati all'URL. Questo non deve ne­ces­sa­ria­men­te trovarsi sullo stesso dominio Internet dell'host con­tat­ta­to, che viene in questo modo informato dei tentativi di con­fi­gu­ra­zio­ne non riusciti.

Se volete sfruttare le pos­si­bi­li­tà dell'HPKP, dovete anzitutto decidere su quale chiave pubblica o quali chiavi pubbliche eseguire il pinning. In linea di principio potete scegliere qualsiasi chiave pubblica contenuta nella catena dei cer­ti­fi­ca­ti: può quindi trattarsi di un cer­ti­fi­ca­to root, server o in­ter­me­dio. Se scegliete autorità di cer­ti­fi­ca­zio­ne esterne, tenete presente che tutti i cer­ti­fi­ca­ti emessi da tali autorità verranno sempre con­si­de­ra­ti validi dai client e con­dur­ran­no alla convalida del pin.

Se avete sot­to­po­sto a pinning la vostra chiave server, sarebbe par­ti­co­lar­men­te grave perderla o non poterla uti­liz­za­re a causa di un problema di hardware. Infatti i client, dal momento che hanno salvato il pin e lo con­si­de­ra­no valido per il tempo spe­ci­fi­ca­to al primo accesso, non ac­cet­te­reb­be­ro un nuovo pin prima della scadenza definita. Questo vuol dire che gli utenti non sarebbero più in grado di accedere al server. Per evitare uno scenario di questo tipo, lo standard HPKP (RFC 7569) prevede un pin ag­giun­ti­vo di back-up, che viene fornito anche nel­l'hea­der HTTP e può essere uti­liz­za­to per il rilascio di un nuovo cer­ti­fi­ca­to in caso di emergenza. Questo processo è chiamato Cer­ti­fi­ca­te Signing Request (CSR).

La con­fi­gu­ra­zio­ne del­l'HTTPS è una con­di­zio­ne ne­ces­sa­ria per il fun­zio­na­men­to dell'HPKP sul vostro server. Poiché almeno due chiavi pubbliche devono essere "pinnate", il primo passo è la ge­ne­ra­zio­ne di questi pin. La semplice soluzione per calcolare i valori hash delle chiavi pubbliche esistenti è l'ap­pli­ca­zio­ne open source openssl, uti­liz­za­bi­le tramite la riga di comando del proprio sistema. L'RFC 7469 sta­bi­li­sce il seguente comando standard per i cer­ti­fi­ca­ti X.509:

In questo modo, nel caso del cer­ti­fi­ca­to di esempio cer­ti­fi­ca­te.pem, create la sequenza Base64 per la chiave public.key. Questa viene emessa in forma standard e termina sempre con il segno uguale ("=").

Il passaggio suc­ces­si­vo consiste nel­l'im­po­sta­zio­ne della Cer­ti­fi­ca­te Signing Request (qui: backup.csr) per la vostra chiave di back-up (qui: backup.key):

Con l'aiuto di openssl calcolate infine anche il valore hash di questa chiave:

Poiché la chiave di back-up HPKP so­sti­tui­sce quella standard in caso di bisogno, è opportuno salvarla se­pa­ra­ta­men­te. La soluzione migliore è quella di uti­liz­za­re una piat­ta­for­ma di ar­chi­via­zio­ne esterna che sia rag­giun­gi­bi­le sempre e da qualunque luogo. Al­tret­tan­to rac­co­man­da­bi­le è l'impiego di un password manager: pro­teg­gen­do il CSR e la chiave cor­ri­spon­den­te nella vostra banca dati tramite un software di questo tipo, potete sentirvi al sicuro e avere la chiave di back-up pronta all'uso in qualsiasi momento.

Il modello Trust on First Use, come detto sopra, prevede che l'HPKP entri in effetto subito dopo il primo contatto del client. Questo significa che la prima visita, nel corso della quale il server trasmette le chiavi, non gode della pro­te­zio­ne di questa procedura. Sebbene questo piccolo gap possa causare degli in­con­ve­nien­ti in casi isolati, di fatto non correte un gran rischio di subire un attacco alle con­nes­sio­ni SSL/TLS del vostro sito. La critica prin­ci­pa­le che viene mossa nei confronti del public key pinning riguarda uno scenario in par­ti­co­la­re, reso possibile proprio dal­l'im­pie­go della tecnica del pinning ed esem­pli­fi­ca­to come segue:

1. Un ag­gres­so­re vuole attaccare il vostro sito e ottiene l'accesso al server.
2. L'ag­gres­so­re installa un nuovo cer­ti­fi­ca­to SSL/TLS e crea il proprio paio di chiavi.
3. L'ag­gres­so­re genera il valore hash ap­pro­pria­to per la chiave pubblica e lo inserisce al posto del vostro pin nell'area cor­ri­spon­den­te del­l'hea­der del cer­ti­fi­ca­to pinnato.
4. Gli utenti e i client che entrano in contatto con il vostro sito per la prima volta ottengono in questo modo il pin sbagliato e non sono più in grado di stabilire una con­nes­sio­ne sicura con il vostro server.
5. Se l'ag­gres­so­re cancella di nuovo il cer­ti­fi­ca­to dal vostro server, a questi utenti con­ti­nue­rà a essere impedito l'accesso per tutto il periodo di validità del pin sbagliato.
6. Oltre ai danni inflitti dalla perdita di traffico, l'ag­gres­so­re in teoria ha anche la pos­si­bi­li­tà di ri­cat­tar­vi chie­den­do­vi del denaro per lo sblocco del cer­ti­fi­ca­to falso.

Anche se questo scenario è in teoria possibile, non è cer­ta­men­te un valido argomento contro l'HTTP Public Key Pinning: infatti l'ag­gres­so­re potrebbe comunque impostare da solo l'e­sten­sio­ne del pro­to­col­lo HTTP, non appena ottenuto l'accesso al server. Il punto fon­da­men­ta­le resta l'im­por­tan­za di pro­teg­ge­re il vostro sito dagli attacchi degli hacker. Se uti­liz­za­te i pin, dovreste anche fare in modo che il software di mo­ni­to­rag­gio vi informi im­me­dia­ta­men­te delle modifiche alle in­te­sta­zio­ni HPKP in modo da poter agire in tempo utile. Un'e­ven­tua­le soluzione lato client potrebbe essere il mec­ca­ni­smo di reset dei pin che elimini re­go­lar­men­te quelli maligni.

Altri punti critici ri­co­no­sciu­ti sono la scarsa dif­fu­sio­ne e la com­ples­si­tà di con­fi­gu­ra­zio­ne del public key pinning, dovute pro­ba­bil­men­te al fatto che questo standard è poco co­no­sciu­to o non lo è affatto.