OpenVPN senza CA: come peer-fingerprint verifica i peer

Un piccolo deployment ricorre alle impronte perché un'autorità di certificazione sembra un'infrastruttura per cui nessuno ha tempo. L'istinto è ragionevole, ma la scorciatoia che le persone prendono invece—copiare un segreto del canale dati su entrambe le estremità—non lo è. Una configurazione peer-fingerprint mantiene intatta la struttura TLS: ogni lato conserva la propria chiave privata e il proprio certificato, e ogni lato verifica ancora l'altro. Ciò che cambia è dove è ancorata la verifica: da un emittente fidato a una breve lista di digest fissati. Poiché un digest copre l'intero certificato e non un nome, il rinnovo diventa l'operazione che costa davvero tempo.

A cosa si impegna davvero l'impronta

L'impronta di un certificato è un digest dell'intero certificato codificato in DER, non della sua chiave pubblica e non del nome del suo soggetto. Per questo due certificati con nomi identici e la stessa chiave ma date di validità diverse hanno impronte diverse. È ciò che rende preciso il fissaggio, ed è anche ciò che rende dirompente il rinnovo. Un fissaggio non può significare fidarsi di una chiave in generale, perché nomina un artefatto in un momento della sua vita. Chiunque può conoscere il digest, e conoscerlo non prova nulla di per sé.

openssl x509 -in server.crt -noout -fingerprint -sha256
openssl x509 -in client-07.crt -noout -fingerprint -sha256

Il possesso della chiave privata corrispondente è ciò che prova che il peer detiene quel certificato, e il digest è il modo in cui l'altro lato decide se si aspettava quel certificato. Questa separazione è il motivo per cui questo progetto non è il vecchio accordo a segreto condiviso: una chiave condivisa autentica chiunque conosca gli stessi byte, mentre un fissaggio autentica un certificato. Un dispositivo diverso ottiene la propria voce invece di una copia dello stesso segreto, il che è una piccola differenza nei file e una grande nella portata del danno.

La mappa è reciproca, non simmetrica

Ogni estremità ha bisogno di due cose: la propria chiave privata con il certificato, e una dichiarazione su quali certificati di peer accetterà. Nel client quella dichiarazione è il digest del certificato del server; nel server è l'elenco dei digest dei client registrati. Un esempio ufficiale per configurazioni piccole per Community 2.6 mostra la disposizione con peer-fingerprint, e vale la pena leggerlo prima di scegliere questo modello di fiducia per un deployment reale. Le due direzioni non sono un elenco invertito, e non falliscono nello stesso momento.

Aggiungere un dispositivo modifica una lista di autorizzazione sul server, senza copiare il materiale privato di un client esistente e senza spostare la chiave del server da nessuna parte. Le due direzioni falliscono anche in modo indipendente, il che è utile in fase di diagnosi: il lato che chiude l'handshake è il lato la cui aspettativa non è stata soddisfatta. Se il client rifiuta il server, il digest non corrisponde al certificato presentato. Se il server rifiuta il client, il digest di quel client manca dall'elenco, oppure il client presenta un certificato diverso da quello registrato.

Registrazione: come si unisce un nuovo dispositivo

Generate la chiave e il certificato del nuovo dispositivo dove vivrà la chiave privata, poi spostate solo l'artefatto pubblico verso la parte che deve fissarlo. Trasmettete il digest atteso attraverso un canale di cui vi fidate già, e confrontate il certificato completo invece di un nome che sembra familiare. Un digest copiato dallo stesso download non verificato del certificato prova solo che i due file concordano tra loro. È un controllo di coerenza e non di identità, ed è il modo più silenzioso in cui questo progetto si indebolisce.

Sul server, aggiungere il digest è una modifica di configurazione che passa dal normale gestore ed è seguita da una riconnessione. Confermate che il nuovo dispositivo si connetta e che un dispositivo il cui digest è stato rimosso non lo faccia più. Un test che copre solo il caso positivo lascia la lista di autorizzazione non verificata, ed è esattamente lo stato in cui vi troverete fra sei mesi.

Il rinnovo è il momento costoso

Ogni certificato scade, e un nuovo certificato ha un nuovo digest anche quando la chiave e i nomi restano gli stessi. Sotto un emittente, il rinnovo è trasparente per i peer che si fidano di quell'emittente; sotto il fissaggio, è un evento di registrazione per ogni peer che fissa il certificato.

Pianificate l'ordine prima della data di scadenza e non dopo. Distribuite il nuovo digest alle parti che lo verificano, applicate la modifica, e solo allora sostituite il certificato sull'estremità. Quell'ordine non lascia alcuna finestra in cui i due lati discordano su quale certificato sia attuale. Tenete sotto revisione anche la lista stessa, perché una lista fissata accumula voci per dispositivi dismessi mesi fa. Ogni voce obsoleta è un'identità che si autentica ancora se la sua chiave sopravvive, quindi rimuoverne una è un'azione di sicurezza e non una faccenda domestica.

Cosa non decide la mappa di fiducia

L'autenticazione è uno strato, e la mappa fissata non dice nulla sul pool di indirizzi, sulle rotte spinte, sulla MTU del percorso o sulla politica del firewall. Questi restano configurazione separata con modalità di guasto separate. Un tunnel che si autentica e non passa traffico è un'indagine diversa da uno che non si alza mai.

La mappa inoltre non scala all'infinito, e una PKI basata su emittente è dove finiscono i deployment più grandi. Quella preferenza riguarda le operazioni e non la crittografia, perché aggiungere e ritirare identità attraverso un'unica autorità costa meno che modificare un elenco su ogni peer mentre la flotta cresce. Dove un'implementazione client non supporta l'opzione, la risposta è un modello di fiducia compatibile che quel client documenta, o una sostituzione supportata. Sopprimere l'avviso di verifica non aggiunge quel supporto, e tutto il valore del progetto è che la verifica avvenga ancora.