Kun je een publieke VPN-sleutel delen? Controleer drie dingen

Je kunt je publieke VPN-sleutel aan een peer, een provider of een forum geven, en de tunnel blijft werken. De private sleutel kun je niet overhandigen, zelfs niet aan supportmedewerkers, zonder de identiteit weg te geven die die sleutel bewijst. De beslissing blijft zelden zo zuiver, omdat mensen verwarren naar welke helft van het paar ze kijken, en omdat sommige implementaties de publieke waarde als een naam behandelen. Drie controles beslechten het: welke helft je hebt, waaraan de implementatie die bindt, en wat vervanging kost.

Controle één: welke helft van het paar in je klembord zit

Asymmetrische sleutels komen in paren, en de richting van de afleiding is het hele punt. In WireGuard is de private sleutel 32 willekeurige bytes en de publieke sleutel wordt daaruit berekend; de andere kant op kan niet. wg genkey schrijft de private waarde, wg pubkey leidt de publieke af, en alleen de tweede hoort in een bericht aan een peer.

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

De certificaatwereld gebruikt dezelfde splitsing met meer bewegende delen. Een servercertificaat draagt een publieke sleutel plus namen, en het wordt ondertekend door een private CA-sleutel die de CA nooit verlaat. Een client die die server verifieert, heeft het CA-certificaat nodig, dat openbaar is, en heeft geen enkel nut voor de private ondertekeningssleutel van de CA.

Als je niet zeker weet welke waarde je hebt, zoek dan naar de markering in plaats van de bestandsnaam. Een PEM-blok dat begint met -----BEGIN PRIVATE KEY-----, of de oudere BEGIN RSA PRIVATE KEY-vorm, is de geheime helft. Een waarde die je zonder die markering kunt plakken, is een kandidaat om te delen, afhankelijk van de volgende twee controles.

Controle twee: waaraan de implementatie die publieke waarde bindt

Cryptografische veiligheid en anonimiteit zijn verschillende eigenschappen. De publieke sleutel van een WireGuard-peer is een stabiele identificatie binnen de implementatie: de serverconfiguratie noemt hem, de handshake gebruikt hem als naam, en een beheerder die logs leest ziet elke keer dezelfde tekenreeks wanneer die peer verbindt. Zet de sleutel naast een vraag over je opstelling, en je hebt die tekenreeks gekoppeld aan al het andere in het bericht.

Certificaten lekken identiteit door hun ontwerp. Subject en subject alternative name zijn leesbaar, en voor publiek vertrouwde TLS-certificaten wordt het certificaat zelf gepubliceerd in Certificate Transparency-logs, die doorzoekbaar zijn. Niets daarvan legt een private sleutel bloot, en alles daarvan legt een relatie bloot.

Hier verschillen implementaties, en dat beslist het antwoord. Een wegwerp-testpeer op een labserver is een ander object dan de sleutel die de site-to-site-endpoint van een bedrijf identificeert, ook al zien de bytes er identiek uit.

Controle drie: wat je kunt intrekken, en hoe snel

De derde controle scheidt de twee helften volledig. Een publieke sleutel die is gepubliceerd, kan volgens jouw schema worden vervangen. Een private sleutel die is gepubliceerd, kan niet worden teruggehaald: je eigen kopie verwijderen raakt al genomen kopieën niet, en elke peer die erop vertrouwde, vertrouwt nu iets dat een buitenstaander heeft.

Intrekken is een configuratiehandeling, geen cryptografische. WireGuard levert geen intrekkingslijst, dus je verwijdert de 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 implementaties op basis van certificaten trekken het certificaat in en publiceren een CRL die de server daadwerkelijk controleert via crl-verify. Zonder die richtlijn is de intrekkingslijst decoratie. In beide gevallen is de volgorde hetzelfde: geef een vervanging uit, verspreid die via het ondersteunde kanaal, en zet de oude identiteit daarna buiten gebruik.

De fouten die ontstaan door de drie controles samen te vatten

De meeste echte lekken zijn niet iemand die besluit een private sleutel te publiceren. Het is een heel profiel dat in een forum wordt geplakt: een WireGuard .conf met een PrivateKey-regel, een .ovpn-bundel met een inline sleutelblok, of een screenshot van een clientvenster waar toevallig het sleutelveld op staat. De publieke waarde was waarschijnlijk in orde; die reisde mee met het deel dat dat niet was.

Supportworkflows zijn de tweede bron. Geen enkele legitieme verificatiestap heeft je private sleutel nodig, omdat de andere kant wat nodig is uit de publieke helft afleidt. Als een formulier of een persoon om de private waarde vraagt, is het juiste antwoord de publieke waarde plus de lokale opdracht die hem produceert.

Logs en screenshots vallen in dezelfde categorie. Diagnostische uitvoer kan sleutelmateriaal, sessie-identificaties en interne adressen bevatten, en dat allemaal publiceren om één vraag beantwoord te krijgen ruilt een klein gemak in voor een grotere blootstelling.

Nadat een private waarde is gelekt, zet de identiteit buiten gebruik

Als een private waarde er toch uit is gekomen, behandel die identiteit dan als buiten gebruik. Genereer een nieuw paar, installeer de publieke helft waar peers die verwachten, verwijder de oude peer of trek het oude certificaat in, en controleer de plekken waar je het hebt gepubliceerd. Je kunt kopieën die je niet beheert niet verwijderen, dus verwijderen gaat over de toekomst, niet over het verleden.

Schrijf daarna de distributie op: welke sleutel bij welk apparaat hoort, wie een kopie heeft, hoe een vervanging wordt geleverd, en wie een buiten gebruik gestelde peer verwijdert. Dat zijn de delen die mensen vergeten, en ze bepalen hoe lang een lek nuttig blijft.