Come verificare l’impronta di un certificato VPN su un canale separato
Un’impronta dimostra l’identità solo quando il valore atteso arriva da un canale che l’attaccante non controlla. Eseguite la verifica in questo ordine.
Un’impronta vale quanto il canale che vi ha detto cosa aspettarvi. Se il valore con cui confrontate è arrivato sulla stessa connessione che state testando, il confronto non dimostra nulla oltre al fatto che chi controlla quella connessione è coerente. La verifica deve seguire un ordine fisso, e un passo fallito dovrebbe fermarvi invece di spingervi al successivo. Questo è l’ordine che uso quando un client VPN segnala che un certificato è cambiato.
Nominate l’oggetto prima di nominare il valore
Decidete se il valore atteso appartiene al certificato foglia del server, all’autorità emittente CA o alla chiave pubblica dentro la foglia. Sono tre verifiche diverse e falliscono in modi diversi. Un’impronta CA che corrisponde non fissa il server, e un hash della chiave pubblica sopravvive deliberatamente a una riemissione che conserva la stessa chiave.
Annotate anche l’algoritmo. SHA-256 è l’attesa normale oggi, ma gli strumenti più vecchi stampavano SHA-1 a meno che non chiedeste altro, e un valore esadecimale di 40 caratteri è il segno che state per confrontare due cose diverse.
Ottenete il valore atteso tramite un secondo canale
Il secondo canale deve essere uno in cui la parte da cui vi proteggete non possa scrivere. Un sistema di provisioning su cui vi autenticate già, un registro stampato in cassaforte, un database di configurazione o un documento firmato consegnato da un altro processo vanno tutti bene. Un messaggio di chat di un collega, una pagina di assistenza raggiunta tramite un risultato di ricerca e qualunque cosa incollata nel terminale in cui state già facendo debug non vanno bene.
Chiedete il valore completo e l’algoritmo, mai un prefisso. I due punti e maiuscole o minuscole non contano, ma il troncamento trasforma una verifica a 256 bit in un gioco di indovinelli.
Se nessuno può produrre il valore atteso da una fonte indipendente, il risultato onesto è che questo certificato oggi non è verificabile. Dirlo è meglio che fissare ciò che il client ha appena mostrato, il che trasforma un avviso in un’abitudine.
Estraete il valore dalla vostra parte
Per un file di certificato, il comando è openssl x509 -in server.crt -noout -fingerprint -sha256. Il digest esplicito conta: senza di esso, l’output dipende dalla vostra versione di OpenSSL. Il risultato è una stringa esadecimale separata da due punti, quindi togliete i due punti e portate entrambi i lati in minuscolo prima di confrontare.
Per un endpoint che parla TLS direttamente, collegatevi e fate uscire il certificato con una pipe: openssl s_client -connect vpn.example.com:443 -servername vpn.example.com < /dev/null | openssl x509 -noout -fingerprint -sha256. Funziona per un pannello di amministrazione web o un listener TLS, non per OpenVPN, il cui canale di controllo sta dentro il tunnel. Per OpenVPN, leggete il certificato dal profilo su disco invece di provare a catturarlo dal socket.
Il confronto deve essere meccanico. Normalizzate entrambi i valori con tr -d ':' e una conversione in minuscolo, poi confrontate l’intera stringa. Farlo a occhio è il modo in cui un prefisso corrispondente nasconde una differenza nell’ultimo byte. Se le stringhe differiscono, trattate la differenza come reale prima di cercare una spiegazione.
Condizioni di arresto
Fermatevi se l’oggetto differisce, perché un’impronta CA non può scagionare un certificato foglia e una foglia non può scagionare la CA. Fermatevi se l’algoritmo differisce, perché un valore SHA-1 confrontato con un valore SHA-256 non vi dice nulla. Fermatevi se l’impronta corrisponde ma il certificato è scaduto, revocato o emesso per un altro nome; un hash corrispondente non è un controllo di validità e non ripara una catena rotta. Fermatevi anche se il numero di serie non corrisponde al numero di serie del registro di riferimento, perché è il modo più economico di individuare un certificato sostituito.
Fermatevi se il nuovo valore è arrivato dal canale che stavate testando. La rotazione può cambiare legittimamente un’impronta, ma il valore sostitutivo deve comunque arrivare dal processo fidato, non dalla finestra di avviso che ha suscitato la domanda.
Fermatevi se la correzione suggerita è disattivare la verifica del nome host o della catena. Un’impronta aggiunge un vincolo alle verifiche normali; non le sostituisce a meno che il deployment abbia scelto deliberatamente un modello di solo pin, e quella scelta porta con sé i propri costi operativi.
Dopo il confronto
Annotate cosa avete confrontato, da dove veniva il valore atteso e quando. Se il certificato è stato riemesso, aggiornate l’attesa memorizzata tramite lo stesso canale fidato e annotate il nuovo numero di serie, perché è il numero di serie che rende verificabile la rotazione successiva.
Poi siate chiari sui limiti. Un’impronta conferma che il certificato che avete è quello che qualcuno vi ha detto di aspettarvi. Non dice nulla sul fatto che l’host sia compromesso, né sul fatto che il servizio registri o limiti ciò che quel certificato può raggiungere.