Si può condividere una chiave pubblica VPN? Controlla tre cose

Puoi consegnare la tua chiave pubblica VPN a un peer, a un provider o a un forum, e il tunnel continua a funzionare. Non puoi consegnare la chiave privata, nemmeno al personale di assistenza, senza consegnare l'identità che quella chiave dimostra. La decisione raramente resta così netta, perché le persone confondono quale metà della coppia stanno guardando, e perché alcune distribuzioni trattano il valore pubblico come un nome. Tre controlli lo risolvono: quale metà possiedi, a cosa la lega la distribuzione, e quanto costa la sostituzione.

Controllo uno: quale metà della coppia è appesa ai tuoi appunti

Le chiavi asimmetriche vanno in coppia, e la direzione della derivazione è tutto il punto. In WireGuard la chiave privata è di 32 byte casuali e la chiave pubblica si calcola da essa; non si può andare nella direzione opposta. wg genkey scrive il valore privato, wg pubkey deriva quello pubblico, e solo il secondo va in un messaggio a un peer.

wg genkey | tee private.key | wg pubkey > public.key
chmod 600 private.key
openssl x509 -noout -pubkey -in server.crt

Il mondo dei certificati usa la stessa divisione con più parti in movimento. Un certificato server porta una chiave pubblica più dei nomi, ed è firmato da una chiave privata CA che non lascia mai la CA. Un client che verifica quel server ha bisogno del certificato CA, che è pubblico, e non ha alcun uso per la chiave di firma privata della CA.

Se non sei sicuro di quale valore stai tenendo, cerca l'indicatore invece del nome del file. Un blocco PEM che inizia con -----BEGIN PRIVATE KEY-----, o la forma più vecchia BEGIN RSA PRIVATE KEY, è la metà segreta. Un valore che puoi incollare senza quell'indicatore è candidato alla condivisione, subordinatamente ai due controlli successivi.

Controllo due: a cosa la distribuzione lega quel valore pubblico

La sicurezza crittografica e l'anonimato sono proprietà diverse. Una chiave pubblica peer WireGuard è un identificatore stabile all'interno della distribuzione: la configurazione del server la elenca, la stretta di mano la nomina, e un amministratore che legge i log vede la stessa stringa ogni volta che quel peer si connette. Se pubblichi la chiave accanto a una domanda sulla tua configurazione, hai collegato quella stringa a tutto il resto del messaggio.

I certificati espongono l'identità per progettazione. Il subject e i subject alternative name sono leggibili, e per i certificati TLS pubblicamente attendibili il certificato stesso viene pubblicato nei log Certificate Transparency, che sono ricercabili. Niente di ciò espone una chiave privata, e tutto ciò espone una relazione.

Qui le distribuzioni differiscono, e questo decide la risposta. Un peer di prova usa e getta su un server di laboratorio è un oggetto diverso dalla chiave che identifica l'endpoint site-to-site di un'azienda, anche se i byte sembrano identici.

Controllo tre: cosa puoi revocare, e quanto in fretta

Il terzo controllo separa completamente le due metà. Una chiave pubblica che è stata pubblicata può essere sostituita secondo i tuoi tempi. Una chiave privata che è stata pubblicata non può essere richiamata: cancellare la tua copia non tocca le copie già prese, e ogni peer che si fidava di essa ora si fida di qualcosa che un estraneo possiede.

La revoca è un'azione di configurazione, non crittografica. WireGuard non fornisce alcuna lista di revoca, quindi rimuovi il peer:

wg set wg0 peer <peer-public-key> remove
# then delete the [Peer] block from the config so it does not return on restart

OpenVPN le distribuzioni basate su certificati revocano il certificato e pubblicano una CRL che il server controlla davvero tramite crl-verify. Senza quella direttiva la lista di revoca è un ornamento. In entrambi i casi la sequenza è la stessa: emetti un sostituto, distribuiscilo tramite il canale supportato, poi ritira la vecchia identità.

Gli errori che derivano dal confondere i tre controlli

La maggior parte delle fughe reali non è una persona che decide di pubblicare una chiave privata. Sono interi profili incollati su un forum: un .conf WireGuard con una riga PrivateKey, un bundle .ovpn con un blocco chiave inline, o lo screenshot della finestra di un client che include per caso il campo della chiave. Il valore pubblico probabilmente andava bene; ha viaggiato con la parte che non andava bene.

I flussi di assistenza sono la seconda fonte. Nessun passaggio di verifica legittimo ha bisogno della tua chiave privata, perché l'altra parte ricava ciò che le serve dalla metà pubblica. Quando un modulo o una persona chiede il valore privato, la risposta corretta è quello pubblico più il comando locale che lo produce.

Log e screenshot appartengono alla stessa categoria. L'output diagnostico può trasportare materiale di chiave, identificatori di sessione e indirizzi interni, e pubblicare tutto ciò per ottenere una risposta scambia un piccolo comodo con un'esposizione maggiore.

Dopo una fuga di un valore privato, ritira l'identità

Se un valore privato è effettivamente uscito, considera quell'identità ritirata. Genera una nuova coppia, installa la metà pubblica dove i peer la aspettano, rimuovi il vecchio peer o revoca il vecchio certificato, e controlla i luoghi in cui l'hai pubblicato. Non puoi cancellare copie che non controlli, quindi la rimozione riguarda il futuro, non il passato.

Poi scrivi la distribuzione: quale chiave appartiene a quale dispositivo, chi ne tiene una copia, come viene consegnato un sostituto, e chi rimuove un peer ritirato. Sono le parti che la gente dimentica, e decidono per quanto tempo una fuga resta utile.