Sie können Ihren öffentlichen VPN-Schlüssel einem Peer, einem Anbieter oder einem Forum geben, und der Tunnel hält weiterhin. Den privaten Schlüssel können Sie nicht übergeben, auch nicht dem Support, ohne die Identität zu übergeben, die dieser Schlüssel belegt. Die Entscheidung bleibt selten so klar, weil Menschen verwechseln, welche Hälfte des Paares sie betrachten, und weil manche Installationen den öffentlichen Wert wie einen Namen behandeln. Drei Prüfungen klären es: welche Hälfte Sie haben, woran die Installation sie bindet und was ein Austausch kostet.

Prüfung eins: welche Hälfte des Paares in Ihrer Zwischenablage liegt

Asymmetrische Schlüssel kommen paarweise, und die Richtung der Ableitung ist der ganze Punkt. Bei WireGuard besteht der private Schlüssel aus 32 zufälligen Bytes, und der öffentliche Schlüssel wird daraus berechnet; der umgekehrte Weg ist unmöglich. wg genkey schreibt den privaten Wert, wg pubkey leitet den öffentlichen ab, und nur der zweite gehört in eine Nachricht an einen Peer.

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

Die Welt der Zertifikate nutzt dieselbe Teilung mit mehr beweglichen Teilen. Ein Serverzertifikat trägt einen öffentlichen Schlüssel plus Namen und wird von einem privaten CA-Schlüssel signiert, der die CA nie verlässt. Ein Client, der diesen Server prüft, braucht das CA-Zertifikat, das öffentlich ist, und hat keinerlei Nutzen für den privaten Signaturschlüssel der CA.

Wenn Sie unsicher sind, welchen Wert Sie halten, achten Sie auf die Markierung statt auf den Dateinamen. Ein PEM-Block, der mit -----BEGIN PRIVATE KEY----- beginnt, oder die ältere Form BEGIN RSA PRIVATE KEY, ist die geheime Hälfte. Ein Wert, den Sie ohne diese Markierung einfügen können, ist ein Kandidat zum Teilen, vorbehaltlich der nächsten beiden Prüfungen.

Prüfung zwei: woran die Installation diesen öffentlichen Wert bindet

Kryptografische Sicherheit und Anonymität sind verschiedene Eigenschaften. Der öffentliche Schlüssel eines WireGuard-Peers ist eine stabile Kennung innerhalb der Installation: die Serverkonfiguration listet ihn, der Handshake benennt ihn, und ein Administrator, der Protokolle liest, sieht dieselbe Zeichenfolge jedes Mal, wenn dieser Peer sich verbindet. Veröffentlichen Sie den Schlüssel neben einer Frage zu Ihrer Einrichtung, haben Sie diese Zeichenfolge mit allem anderen im Beitrag verknüpft.

Zertifikate verraten Identität konstruktionsbedingt. Die Felder Subject und subject alternative name sind lesbar, und bei öffentlich vertrauenswürdigen TLS-Zertifikaten wird das Zertifikat selbst in Certificate-Transparency-Protokollen veröffentlicht, die durchsuchbar sind. Nichts davon legt einen privaten Schlüssel offen, und alles davon legt eine Beziehung offen.

Hier unterscheiden sich Installationen, und das entscheidet die Antwort. Ein Wegwerf-Testpeer auf einem Laborserver ist ein anderes Objekt als der Schlüssel, der den Site-to-Site-Endpunkt eines Unternehmens identifiziert, auch wenn die Bytes identisch aussehen.

Prüfung drei: was Sie widerrufen können und wie schnell

Die dritte Prüfung trennt beide Hälften vollständig. Ein öffentlicher Schlüssel, der veröffentlicht wurde, lässt sich nach Ihrem Zeitplan ersetzen. Ein privater Schlüssel, der veröffentlicht wurde, lässt sich nicht zurückholen: das Löschen Ihrer Kopie berührt bereits gezogene Kopien nicht, und jeder Peer, der ihm vertraute, vertraut nun etwas, das ein Außenstehender hält.

Widerruf ist eine Konfigurationshandlung, keine kryptografische. WireGuard liefert keine Widerrufsliste, also entfernen Sie den 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 Installationen auf Zertifikatsbasis widerrufen das Zertifikat und veröffentlichen eine CRL, die der Server tatsächlich über crl-verify prüft. Ohne diese Direktive ist die Widerrufsliste reine Dekoration. So oder so ist die Reihenfolge dieselbe: einen Ersatz ausstellen, ihn über den unterstützten Kanal verteilen und dann die alte Identität außer Betrieb nehmen.

Die Fehler, die aus dem Zusammenlegen der drei Prüfungen entstehen

Die meisten echten Lecks sind kein Mensch, der beschließt, einen privaten Schlüssel zu veröffentlichen. Es ist ein ganzes Profil, das in ein Forum eingefügt wird: eine WireGuard-.conf-Datei mit einer PrivateKey-Zeile, ein .ovpn-Bündel mit eingebettetem Schlüsselblock oder ein Screenshot eines Clientfensters, das zufällig das Schlüsselfeld enthält. Der öffentliche Wert war wahrscheinlich in Ordnung; er reiste mit dem Teil, der es nicht war.

Support-Abläufe sind die zweite Quelle. Kein legitimer Prüfschritt braucht Ihren privaten Schlüssel, weil die andere Seite das Nötige aus der öffentlichen Hälfte ableitet. Wenn ein Formular oder eine Person nach dem privaten Wert fragt, ist die richtige Antwort der öffentliche plus der lokale Befehl, der ihn erzeugt.

Protokolle und Screenshots gehören in dieselbe Kategorie. Diagnoseausgaben können Schlüsselmaterial, Sitzungskennungen und interne Adressen tragen, und alles davon zu posten, um eine Frage beantwortet zu bekommen, tauscht einen kleinen Komfort gegen eine größere Exposition.

Nach einem Leck eines privaten Werts: die Identität außer Betrieb nehmen

Wenn ein privater Wert doch nach außen gelangt ist, behandeln Sie diese Identität als stillgelegt. Erzeugen Sie ein neues Paar, installieren Sie die öffentliche Hälfte dort, wo Peers sie erwarten, entfernen Sie den alten Peer oder widerrufen Sie das alte Zertifikat, und prüfen Sie die Stellen, an denen Sie es veröffentlicht haben. Kopien, die Sie nicht kontrollieren, können Sie nicht löschen, also geht es beim Entfernen um die Zukunft, nicht um die Vergangenheit.

Schreiben Sie dann die Verteilung auf: welcher Schlüssel zu welchem Gerät gehört, wer eine Kopie hält, wie ein Ersatz zugestellt wird und wer einen stillgelegten Peer entfernt. Das sind die Teile, die Menschen vergessen, und sie entscheiden, wie lange ein Leck nützlich bleibt.

Ähnliche Artikel