Ist dieser veröffentlichte OpenVPN-Schlüssel eine CA, ein Peer-Schlüssel oder tls-auth?

Jemand meldet, der VPN-Schlüssel sei öffentlich, und dieser Satz verbirgt drei völlig verschiedene Situationen. Es kann sich um ein CA-Zertifikat handeln, das jeder Client haben sollte, um einen privaten Identitätsschlüssel, der niemals eine Maschine hätte verlassen dürfen, oder um ein gemeinsames Geheimnis des Steuerkanals, das beide Seiten halten müssen. Die Reparatur, die Dringlichkeit und der Schadensradius unterscheiden sich in jedem Fall, deshalb ist die erste Aufgabe die Klassifizierung und nicht das Handeln. Wer die Kategorie falsch bestimmt, für den ist jeder weitere Schritt vergeudete Mühe.

Beginne bei der Direktive, nicht beim Dateinamen

Lies die aktive Konfiguration und finde heraus, welche Direktive auf das fragliche Material zeigt. Die TLS-Optionen von OpenVPN verwenden ca für vertrauenswürdiges Zertifikatmaterial, cert für das Zertifikat des lokalen Peers und key für den dazugehörigen privaten Schlüssel.

Dateinamen beweisen nichts. Eine Datei namens key.pem kann ein Zertifikat enthalten, und ein eingebetteter Block im Profil kann genau dasselbe Objekt enthalten wie eine separate Datei auf der Festplatte. Öffne die Datei und sieh dir ihren Header an, statt dem Namen zu vertrauen. Diese eine Prüfung beseitigt den größten Teil der Unklarheit im Bericht.

Ist das Profil ein PKCS#12-Bündel, packe es an einem kontrollierten Ort aus, um zu sehen, was tatsächlich darin steckt. Ein einzelnes Bündel kann ein Zertifikat, dessen Kette und einen privaten Schlüssel enthalten, was bedeutet, dass ein Leck des Bündels ein Leck aller drei ist.

Schreibe die Klassifizierung auf, bevor jemand eine Datei ändert: Objekt, Direktive, welche Peers sie halten und wer sie lesen kann. Von diesem Satz hängt der Rest der Reaktion ab.

Ein CA-Zertifikat ist zum Teilen gedacht

Ein öffentliches CA-Zertifikat ist Vertrauensmaterial. Clients brauchen es, um den Server zu verifizieren, und es zu verteilen ist der Normalfall und kein Vorfall. Es zu veröffentlichen veröffentlicht nicht den privaten Signaturschlüssel der CA, und genau dieses Objekt würde es einem Angreifer erlauben, neue Identitäten zu erzeugen.

Diese Unterscheidung gehört ausdrücklich ins Ticket, weil beide ständig verwechselt werden. Die zu beantwortende Frage ist, ob die geleakte Datei das Zertifikat oder der Signaturschlüssel ist, und ein kurzer Blick in den Dateiinhalt klärt das. Ein Zertifikat enthält einen öffentlichen Schlüssel und eine Signatur; der Signaturschlüssel kommt darin überhaupt nicht vor.

Die Verteilung verdient trotzdem Sorgfalt. Clients sollten das Zertifikat über den freigegebenen Weg zur Profilauslieferung beziehen, nicht von einer Paste-Seite, und ein Zertifikat, das über einen nicht vertrauenswürdigen Weg ankommt, kann unterwegs ersetzt werden.

Ein Peer-Schlüssel und ein tls-auth-Geheimnis sind nicht

Der private Schlüssel eines Peers ist Identitätsmaterial. Sobald er kopiert ist, kann der Server das vorgesehene Gerät nicht mehr von jedem unterscheiden, der die Kopie besitzt, denn der ausschließliche Besitz war die Eigenschaft, die nachgewiesen wurde. Fortgesetzte Autorisierung und Ersetzung sind Entscheidungen des VPN-Betreibers, nicht dessen, der die Datei gefunden hat.

Ein tls-auth-Geheimnis ist etwas Drittes. Es fügt eine HMAC-Authentifizierung um Pakete des Steuerkanals hinzu, sodass falsch authentifizierte Pakete vor einem TLS-Austausch verworfen werden, und es ist weder der private Schlüssel des Peers noch der Schlüssel, der Anwendungsdaten verschlüsselt.

Ist dieses gemeinsame Geheimnis öffentlich, ist die Barriere, die es bot, für alle verschwunden, die es besitzen. Daraus folgt nicht, dass jeder Besitzer die Zertifikats- und Benutzerprüfungen dahinter besteht, weshalb die Klassifizierung wichtiger ist als die Alarmstufe. Sage, welche Barriere gefallen ist, und sage, welche bleiben.

Repariere die Rolle, die geleakt ist, nicht eine benachbarte

Ein gemeinsames Geheimnis lässt sich nicht wieder privat machen, indem man die Datei umbenennt oder den Download-Link versteckt. Ersetzen bedeutet, einen neuen Wert zu erzeugen und ihn in einer koordinierten Änderung an jeden Peer zu verteilen, und nur eine Seite zu ersetzen zerstört die Vereinbarung für alle, die noch den alten Wert halten.

Wurde eine Peer-Identität offengelegt, nutze den Sperr- und Neu-Registrierungsprozess des Betreibers für diese Identität. Das Ändern eines unabhängigen Kontopassworts macht ein kopiertes Zertifikat nicht ungültig, und das Auswechseln der tls-auth-Datei ebenso wenig.

Bestätige, was der eingesetzte Server tatsächlich durchsetzt, bevor du dich auf irgendetwas davon verlässt. Eine Sperrliste, die nicht aktualisiert wird, oder eine Rollenprüfung, die während einer Störung deaktiviert wurde, ändert die Antwort vollständig. Lies die laufende Konfiguration und nicht die Kopie im Repository.

Beurteile vergangenen Verkehr nach seinen eigenen Maßstäben

Eine offengelegte Datei sagt für sich genommen nicht, ob zuvor mitgeschnittene Sitzungen entschlüsselt werden können. Das hängt von der Schlüsselvereinbarungsmethode, dem offengelegten Material und den vorhandenen Aufzeichnungen ab, und sowohl „der gesamte Verkehr ist verloren“ als auch „es ist nichts passiert“ sind ohne diese Fakten Vermutungen.

Veröffentliche keine weitere Kopie der Zugangsdaten, während du fragst, zu welcher Kategorie sie gehört. Teile stattdessen Direktivennamen und nicht geheime Metadaten über den freigegebenen Supportweg.

Die nützliche Schlussfolgerung benennt das Objekt, seine Rolle, den verlorenen Schutz und die erforderliche koordinierte Maßnahme. Alles Kürzere ist eine Schlagzeile und keine Bewertung.