OpenVPN ohne CA: Wie peer-fingerprint Peers verifiziert

Eine kleine Bereitstellung greift zu Fingerabdrücken, weil eine Zertifizierungsstelle wie Infrastruktur aussieht, für die niemand Zeit hat. Der Instinkt ist vernünftig, aber die Abkürzung, die Leute stattdessen wählen—ein Geheimnis des Datenkanals auf beide Enden zu kopieren—ist es nicht. Eine peer-fingerprint-Konfiguration erhält die TLS-Struktur intakt: Jede Seite hält weiterhin ihren eigenen privaten Schlüssel und ihr Zertifikat, und jede Seite verifiziert weiterhin die andere. Was sich ändert, ist der Ankerpunkt der Verifikation: von einer vertrauenswürdigen Ausstellungsstelle zu einer kurzen Liste gepinnter Digests. Weil ein Digest das ganze Zertifikat abdeckt und nicht einen Namen, wird die Erneuerung zum Vorgang, der wirklich Zeit kostet.

Wozu sich der Fingerabdruck tatsächlich verpflichtet

Ein Zertifikatsfingerabdruck ist ein Digest des gesamten DER-kodierten Zertifikats, nicht seines öffentlichen Schlüssels und nicht seines Subjektnamens. Zwei Zertifikate mit identischen Namen und demselben Schlüssel, aber unterschiedlichen Gültigkeitsdaten haben daher unterschiedliche Fingerabdrücke. Das macht Pinning präzise, und es macht auch die Erneuerung störend. Ein Pin kann nicht bedeuten, einem Schlüssel allgemein zu vertrauen, weil er ein Artefakt zu einem Zeitpunkt seines Lebens benennt. Jeder darf den Digest kennen, und ihn zu kennen beweist für sich genommen nichts.

openssl x509 -in server.crt -noout -fingerprint -sha256
openssl x509 -in client-07.crt -noout -fingerprint -sha256

Der Besitz des passenden privaten Schlüssels ist es, der beweist, dass der Peer dieses Zertifikat hält, und der Digest ist, wie die andere Seite entscheidet, ob sie dieses Zertifikat überhaupt erwartet hat. Diese Trennung ist der Grund, warum dieses Design nicht die alte Anordnung mit gemeinsamem Geheimnis ist: Ein gemeinsamer Schlüssel authentifiziert jeden, der dieselben Bytes kennt, während ein Pin ein Zertifikat authentifiziert. Ein anderes Gerät erhält seinen eigenen Eintrag statt einer Kopie desselben Geheimnisses, was ein kleiner Unterschied in Dateien und ein großer im Schadensradius ist.

Die Zuordnung ist wechselseitig, nicht symmetrisch

Jeder Endpunkt braucht zwei Dinge: seinen eigenen privaten Schlüssel samt Zertifikat und eine Aussage darüber, welche Peer-Zertifikate er akzeptiert. Beim Client ist diese Aussage der Digest des Server-Zertifikats; beim Server ist es die Liste der eingetragenen Client-Digests. Ein offizielles Beispiel für kleine Setups für Community 2.6 zeigt die Anordnung mit peer-fingerprint, und es lohnt sich, es zu lesen, bevor Sie dieses Vertrauensmodell für eine echte Bereitstellung wählen. Die beiden Richtungen sind keine umgekehrte Liste, und sie scheitern nicht im selben Moment.

Ein Gerät hinzuzufügen bearbeitet eine Positivliste auf dem Server, ohne privates Material eines bestehenden Clients zu kopieren und ohne den Serverschlüssel irgendwohin zu bewegen. Die beiden Richtungen scheitern zudem unabhängig, was bei der Diagnose nützlich ist: Welche Seite den Handshake schließt, ist die Seite, deren Erwartung nicht erfüllt wurde. Wenn der Client den Server ablehnt, passt der Digest nicht zu dem präsentierten Zertifikat. Wenn der Server den Client ablehnt, fehlt der Digest dieses Clients in der Liste, oder der Client präsentiert ein anderes Zertifikat als das eingetragene.

Registrierung: wie ein neues Gerät beitritt

Erzeugen Sie Schlüssel und Zertifikat des neuen Geräts dort, wo der private Schlüssel leben wird, und bewegen Sie dann nur das öffentliche Artefakt zu der Partei, die es pinnen muss. Übertragen Sie den erwarteten Digest über einen Kanal, dem Sie bereits vertrauen, und vergleichen Sie das vollständige Zertifikat statt eines Namens, der vertraut aussieht. Ein Digest, der aus demselben ungeprüften Download wie das Zertifikat kopiert wurde, beweist nur, dass die beiden Dateien zueinander passen. Das ist eine Konsistenzprüfung und keine Identitätsprüfung, und es ist der leiseste Weg, auf dem dieses Design geschwächt wird.

Auf dem Server ist das Hinzufügen des Digests eine Konfigurationsänderung, die über den normalen Manager läuft und von einer erneuten Verbindung gefolgt wird. Bestätigen Sie, dass das neue Gerät sich verbindet und dass ein Gerät, dessen Digest entfernt wurde, es nicht mehr tut. Ein Test, der nur den positiven Fall abdeckt, lässt die Positivliste ungeprüft, und genau in diesem Zustand werden Sie in sechs Monaten sein.

Die Erneuerung ist der teure Moment

Jedes Zertifikat läuft ab, und ein neues Zertifikat hat einen neuen Digest, selbst wenn Schlüssel und Namen gleich bleiben. Unter einer Ausstellungsstelle ist die Erneuerung für Peers transparent, die dieser Stelle vertrauen; unter Pinning ist sie ein Eintragungsereignis für jeden Peer, der das Zertifikat pinnt.

Planen Sie die Reihenfolge vor dem Ablaufdatum statt danach. Verteilen Sie den neuen Digest an die Parteien, die ihn verifizieren, wenden Sie die Änderung an, und tauschen Sie erst dann das Zertifikat am Endpunkt. Diese Reihenfolge lässt kein Fenster, in dem die beiden Seiten uneinig sind, welches Zertifikat aktuell ist. Halten Sie auch die Liste selbst unter Prüfung, denn eine gepinnte Liste sammelt Einträge für Geräte, die vor Monaten außer Betrieb genommen wurden. Jeder veraltete Eintrag ist eine Identität, die sich noch authentifiziert, wenn ihr Schlüssel überlebt, also ist das Entfernen eines Eintrags eine Sicherheitsmaßnahme und keine Aufräumarbeit.

Was die Vertrauenszuordnung nicht entscheidet

Authentifizierung ist eine Schicht, und die gepinnte Zuordnung sagt nichts über den Adresspool, die geschobenen Routen, die Pfad-MTU oder die Firewall-Richtlinie. Diese bleiben getrennte Konfiguration mit getrennten Fehlermodi. Ein Tunnel, der sich authentifiziert und keinen Verkehr durchlässt, ist eine andere Untersuchung als einer, der nie hochkommt.

Die Zuordnung skaliert auch nicht unbegrenzt, und eine ausstellerbasierte PKI ist der Ort, an dem größere Bereitstellungen landen. Diese Vorliebe betrifft den Betrieb und nicht die Kryptografie, denn Identitäten über eine Autorität hinzuzufügen und zurückzuziehen ist billiger, als bei wachsender Flotte eine Liste auf jedem Peer zu bearbeiten. Wo eine Client-Implementierung die Option nicht unterstützt, ist die Antwort ein kompatibles Vertrauensmodell, das dieser Client dokumentiert, oder ein unterstützter Ersatz. Die Verifikationswarnung zu unterdrücken fügt diese Unterstützung nicht hinzu, und der ganze Wert des Designs ist, dass Verifikation weiterhin stattfindet.