Sollten Sie zwei VPN-Schichten stapeln? Drei Bedingungen zur Prüfung

Bevor Sie eine zweite Verschlüsselungsschicht zu einem VPN hinzufügen, beantworten Sie ehrlich eine Frage: Was hält der Beobachter noch in der Hand, nachdem beide Schichten ihre Arbeit getan haben? Ist die Antwort der innere Geheimtext, unverändert, dann hat die Verschachtelung Zeit gekauft und sonst nichts. Was folgt, ist ein Entscheidungsverfahren, keine Empfehlung. Dasselbe Diagramm ist in einer Bereitstellung verschwendete CPU und in einer anderen die richtige Antwort, und nur drei Bedingungen trennen beides.

Notieren Sie, was der Beobachter behält

Halten Sie das Objekt fest, das ein Angreifer heute speichern kann, und dann die Abfolge von Entfernungen, die irgendwann Klartext freilegen würde. Ein äußerer Tunnel erzeugt Geheimtext; endet sein Schutz, bleibt der Geheimtext des inneren Tunnels übrig, weiterhin versiegelt. Eine Hülle zu entfernen ist keine Entschlüsselung. Dieser Satz beschreibt Verschachtelung, und er gilt nur, solange der innere Schlüssel überlebt. In dem Moment, in dem beide Schichten irgendetwas teilen, fällt die Zeitachse zu einem einzigen Ereignis zusammen.

Das nützliche Artefakt ist also eine Zeitachse, kein Kästchendiagramm. Notieren Sie für jede Schicht den Endpunkt, den Schlüsselinhaber, die Identitätsprüfung und das Jahr, in dem die Annahme voraussichtlich versagt.

Eine praktische Methode, die eigene Behauptung zu prüfen: Nehmen Sie an, der Beobachter zeichnet alles auf und gibt nie auf. Unter dieser Annahme, schützt das Design die Nutzlast noch für die geforderte Lebensdauer? Hängt die Antwort davon ab, dass der Beobachter beschließt, keinen Verkehr zu speichern, hat das Design keine Antwort.

Bedingung eins: enden die Schichten an verschiedenen Orten?

Verschachtelung lohnt sich, wenn die beiden Schichten in unterschiedlichen Vertrauensdomänen enden, etwa ein anbieterverwaltetes IPsec-Gateway vor einem Tunnel auf Anwendungsebene, der in Ihrem eigenen Netz endet. Dann liefert ein Bruch der äußeren Schicht Geheimtext, den nur Ihr Host öffnen kann, und der Anbieter sieht zu keinem Zeitpunkt Klartext. Legen Sie beide Schichten auf dasselbe Gateway, und diese Eigenschaft verschwindet. Wer die Box kompromittiert, liest den Verkehr zwischen den beiden Entschlüsselungsvorgängen, egal wie viele Hüllen das Diagramm zeigt.

Prüfen Sie das am installierten Zustand statt am Design. Unter Linux listet ip xfrm state jede Sicherheitsassoziation und ihre Endpunkte auf, was klärt, wo jede Schicht tatsächlich endet.

Bedingung zwei: ist das Schlüsselmaterial tatsächlich unabhängig?

Zwei Schichten aus einem Zertifikat, einem vorab geteilten Schlüssel oder einer Herstellerbibliothek sind eine Schicht mit zusätzlichen Schritten. Dann öffnet eine einzige kompromittierte Berechtigung beide, und ein einziger Implementierungsfehler entfernt beide auf einmal. Unabhängigkeit muss in der Konfiguration sichtbar sein, nicht auf einer Folie behauptet werden.

Hier schlägt hybride Schlüsseletablierung das Stapeln von Tunneln. IKEv2 kann mehrere Schlüsselaustausche in einer Verhandlung führen, sodass eine klassische Gruppe und ein Post-Quanten-KEM beide dieselben Sitzungsschlüssel speisen können, statt umeinander gewickelt zu werden. Das Ergebnis ist eine Sicherheitsassoziation, deren Schlüssel von beiden Geheimnissen abhängen, und ein Angreifer muss beide brechen. Das ist eine dokumentierte Konstruktion mit definierter Zusammensetzung, was ein selbstgebauter Stapel aus zwei VPN-Produkten nicht ist. Unter strongSwan gibt swanctl --list-sas den ausgehandelten Vorschlag für jede SA aus, und so bestätigen Sie, was tatsächlich lief, statt was Sie konfiguriert haben.

Bedingung drei: überleben die Daten die äußere Annahme?

Eine Schicht, die zwanzig Jahre halten muss, braucht ein Zwanzig-Jahres-Argument. Jetzt aufzuzeichnen und später zu entschlüsseln ist billig, und deshalb kann eine klassische äußere Schicht nicht als vorübergehende Hülle um etwas Stärkeres behandelt werden.

Fragen Sie, wann jeder Schlüssel wiederherstellbar wird, nicht ob die Chiffre heute gebrochen ist. Ein statischer Schlüsselaustausch ohne Forward Secrecy versagt rückwirkend an dem Tag, an dem der private Schlüssel fällt. Ephemere Schlüsselvereinbarung versagt nur für Sitzungen, die ein Angreifer angreifen kann, während sie live sind, oder wenn der Algorithmus selbst schwächer wird. Dieser Unterschied entscheidet, ob eine innere Schicht 2040 noch hilft. Er entscheidet auch, ob die äußere Schicht überhaupt etwas ändert, denn eine äußere Schicht mit der schwächeren Schlüssellebensdauer wird einfach zum frühesten Punkt auf der Zeitachse.

Was stattdessen zu bauen ist, wenn die Antwort nein lautet

Wenn eine der drei Bedingungen scheitert, lassen Sie die Verschachtelung und stecken Sie den Aufwand in die Schicht, die die Lebensdaueranforderung tatsächlich trägt. Konfigurieren Sie einen hybriden Schlüsselaustausch in dem Protokoll, das Sie bereits betreiben, halten Sie die Implementierung aktuell und schreiben Sie die Zusammensetzung auf, auf die Sie sich verlassen. ML-KEM in einem Designdokument zu nennen ist keine Sicherheitseigenschaft, und FIPS 203 definiert den Schlüsselverkapselungsmechanismus, nicht Ihren Tunnel.

Wo eine zweite Schicht ihren Platz wirklich verdient, beschreiben Sie sie als Verteidigung in der Tiefe statt als Beweis. Prüfen Sie dann die Zusammensetzung: welcher Endpunkt welchen Schlüssel hält, welche Identität jede Seite prüft und was ein Betreiber mit Konsolenzugriff lesen kann. Ein Design, das diese drei Fragen übersteht, ist die zusätzliche CPU wert. Eines, das es nicht tut, ist ein Diagramm.

Erfassen Sie vor dem Änderungsfenster die aktuelle SA-Tabelle und die ausgehandelten Vorschläge, und danach erfassen Sie sie erneut und vergleichen Sie, denn der einzige Beweis, der zählt, ist, worauf sich die Geräte tatsächlich geeinigt haben.