Kan du dela en publik VPN-nyckel? Kontrollera tre saker

Du kan ge din publika VPN-nyckel till en peer, en leverantör eller ett forum, och tunneln fortsätter att fungera. Den privata nyckeln kan du inte lämna ut, inte ens till supportpersonal, utan att lämna ut den identitet som nyckeln bevisar. Beslutet är sällan så enkelt, eftersom människor blandar ihop vilken halva av paret de tittar på, och eftersom vissa driftsättningar behandlar det publika värdet som ett namn. Tre kontroller avgör saken: vilken halva du har, vad driftsättningen binder den till, och vad ett byte kostar.

Kontroll ett: vilken halva av paret som ligger i urklipp

Asymmetriska nycklar kommer i par, och riktningen på härledningen är hela poängen. I WireGuard är den privata nyckeln 32 slumpmässiga byte och den publika nyckeln beräknas från den; åt andra hållet går det inte. wg genkey skriver det privata värdet, wg pubkey härleder det publika, och bara den andra hör hemma i ett meddelande till en peer.

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

Certifikatvärlden använder samma uppdelning med fler rörliga delar. Ett servercertifikat bär en publik nyckel plus namn, och det signeras av en privat CA-nyckel som aldrig lämnar CA:n. En klient som verifierar den servern behöver CA-certifikatet, som är offentligt, och har ingen nytta av CA:ns privata signeringsnyckel.

Om du är osäker på vilket värde du håller, leta efter markören i stället för filnamnet. Ett PEM-block som börjar med -----BEGIN PRIVATE KEY-----, eller den äldre BEGIN RSA PRIVATE KEY-formen, är den hemliga halvan. Ett värde du kan klistra in utan den markören är en kandidat för delning, med förbehåll för de två nästa kontrollerna.

Kontroll två: vad driftsättningen binder till det publika värdet

Kryptografisk säkerhet och anonymitet är olika egenskaper. En WireGuard-peers publika nyckel är en stabil identifierare inom driftsättningen: serverkonfigurationen listar den, handskakningen namnger den, och en administratör som läser loggar ser samma sträng varje gång den peeren ansluter. Om du publicerar nyckeln bredvid en fråga om din uppsättning har du kopplat strängen till allt annat i inlägget.

Certifikat läcker identitet genom sin design. Subject och subject alternative name är läsbara, och för allmänt betrodda TLS-certifikat publiceras själva certifikatet i Certificate Transparency-loggar, som är sökbara. Inget av detta avslöjar en privat nyckel, och allt av det avslöjar en relation.

Här skiljer sig driftsättningarna, och det avgör svaret. En engångstestpeer på en labbserver är ett annat objekt än nyckeln som identifierar ett företags site-to-site-slutpunkt, även om byten ser identiska ut.

Kontroll tre: vad du kan återkalla, och hur snabbt

Den tredje kontrollen skiljer de två halvorna helt. En publik nyckel som publicerats kan bytas ut enligt din planering. En privat nyckel som publicerats kan inte återkallas: att radera din kopia rör inte kopior som redan tagits, och varje peer som litade på den litar nu på något som en utomstående har.

Återkallelse är en konfigurationsåtgärd, inte en kryptografisk. WireGuard levererar ingen återkallelselista, så du tar bort peeren:

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

OpenVPN driftsättningar byggda på certifikat återkallar certifikatet och publicerar en CRL som servern faktiskt kontrollerar via crl-verify. Utan det direktivet är återkallelselistan bara dekoration. I båda fallen är ordningen densamma: utfärda en ersättning, distribuera den via den stödda kanalen och pensionera sedan den gamla identiteten.

Felen som uppstår när de tre kontrollerna slås ihop

De flesta verkliga läckor är inte en person som bestämmer sig för att publicera en privat nyckel. De är en hel profil inklistrad på ett forum: en WireGuard .conf med en PrivateKey rad, ett .ovpn paket med ett inbäddat nyckelblock, eller en skärmbild av ett klientfönster som råkar innehålla nyckelfältet. Det publika värdet var förmodligen okej; det följde med den del som inte var det.

Supportarbetsflöden är den andra källan. Inget legitimt verifieringssteg behöver din privata nyckel, eftersom andra sidan härleder det den behöver från den publika halvan. När ett formulär eller en person ber om det privata värdet är rätt svar det publika värdet plus det lokala kommando som skapar det.

Loggar och skärmbilder hör till samma kategori. Diagnostisk utdata kan bära nyckelmaterial, sessionsidentifierare och interna adresser, och att publicera allt detta för att få svar på en fråga byter en liten bekvämlighet mot en större exponering.

Efter att ett privat värde läckt, pensionera identiteten

Om ett privat värde faktiskt kom ut, behandla den identiteten som pensionerad. Generera ett nytt par, installera den publika halvan där peerarna förväntar sig den, ta bort den gamla peeren eller återkalla det gamla certifikatet, och kontrollera platserna där du publicerade det. Du kan inte radera kopior du inte kontrollerar, så borttagning handlar om framtiden, inte det förflutna.

Skriv sedan ned distributionen: vilken nyckel som hör till vilken enhet, vem som håller en kopia, hur en ersättning levereras, och vem som tar bort en pensionerad peer. Det är delarna folk glömmer, och de avgör hur länge en läcka förblir användbar.