TLS-VPN gegen IPsec: die fünf Felder, die eine Prüfung verdienen

TLS-VPNs gegen IPsec-VPNs nach Protokollfamilie zu sortieren, beantwortet eine Frage, die niemand gestellt hat, und zitiert meist eine Konstruktion, die beide Familien vor Jahren aufgegeben haben. Was eine prüfende Person tatsächlich bewerten kann, sind der ausgehandelte Schutz, die Peer-Identität, das Clientmodell und der exponierte Dienst. Diese vier Dinge sind in einem Deployment sichtbar, und keines davon folgt aus dem Produktetikett. Fragen Sie nach fünf Feldern, und das Gespräch wird konkret.

Fünf Felder – und das Etikett gehört nicht dazu

Das erste Feld ist die unterstützte Softwareversion, denn eine Protokollbeschreibung ohne Version ist ein Prospekt. Das zweite ist die ausgehandelte Protokollversion, die entscheidet, welche Konstruktionen überhaupt verfügbar sind. Das dritte ist die Schutzsuite, das vierte die Authentifizierungsmethode für Peer und Nutzer, und das fünfte der Zugriffsumfang, den das Produkt nach der Zulassung gewährt.

Ein SSL-VPN-Etikett deckt mindestens drei verschiedene Produkte ab: einen vollwertigen Netzwerkclient, einen Anwendungsproxy und ein altes browserbasiertes Portal. Sie exponieren unterschiedliche Dienste und scheitern unterschiedlich, daher kann das Etikett das Feld Zugriffsumfang nicht ersetzen.

Was authentifizierte Verschlüsselung tatsächlich ändert

TLS 1.3 verlangt authentifizierte Verschlüsselung, was die ältere MAC-then-encrypt-Konstruktion aus dem Protokoll entfernt, statt sie optional zu lassen. IPsec ESP hat genauso lange Suiten für authentifizierte Verschlüsselung, mit AES-GCM in einer eigenen RFC. In beiden Familien stammt die Garantie aus der ausgehandelten Suite und nicht aus dem Familiennamen, weshalb die Feldliste mit einer Version beginnt. Wer die Suite nicht nennen kann, hat nichts zu bewerten.

Deshalb ist der historische Vergleich irreführend. Ein Deployment, das auf eine alte TLS-Version mit einer CBC-Suite festgelegt ist, und eines, das TLS 1.3 mit einer AEAD-Suite fährt, sind nicht dieselbe Sicherheitslage, auch wenn beide TLS-VPNs sind. Dieselbe Spaltung gibt es auf der IPsec-Seite zwischen einer modernen ESP-Suite und einer alten Kombination.

Lesen Sie die ausgehandelten Werte statt der beabsichtigten Konfiguration. Die Befehle unten zeigen, worauf sich ein laufender Endpunkt und ein laufender Tunnel tatsächlich geeinigt haben.

openssl s_client -connect vpn.lab.example:443 -tls1_3 -brief
ip xfrm state
swanctl --list-sas

Wenn der Endpunkt TLS 1.3 nicht aushandeln will, ist das ein Befund und keine Vorliebe. Wenn der Tunnel eine Suite auflistet, die Sie nicht erwartet haben, zählt die Konfiguration, die die Peers gewählt haben, nicht die in der Vorlage.

Peer-Identität ist eine eigene Frage

Verschlüsselung ohne verifizierten Peer schützt den Verkehr vor Beobachtern und übergibt ihn an wen auch immer die Verbindung beantwortet hat. Peer-Authentifizierung fragt, welche Identität erwartet wird, welches Vertrauensmaterial sie validiert und wie sich der Client verhält, wenn die Antwort nicht passt. Eine Zertifikatskette, ein gepinnter Schlüssel und ein vorab geteiltes Geheimnis sind drei verschiedene Antworten mit drei verschiedenen Betriebskosten.

Stellen Sie dann dieselben Fragen zum Nutzer oder Gerät. Ein Gateway, das die Maschine authentifiziert und jeden Nutzer zulässt, oder umgekehrt, hat eine bestimmte Haltung, die dokumentiert statt angenommen werden sollte. Ressourcenberechtigungen nach der Zulassung gehören zum selben Feld, denn Authentifizierung ist keine Autorisierung.

Hostnamen- und Zertifikatsprüfungen zu erhalten, ist wichtiger als die Vertrautheit des Anmeldefensters. Ein Client, der so konfiguriert ist, die Verifikation zu ignorieren, hat den einzigen Schritt entfernt, der Ihr Gateway von einer überzeugenden Nachbildung unterscheidet.

Die Grenze, die das Produkt exponiert

Ein clientloses Portal leitet ausgewählte Anwendungsoperationen durch das Gateway, sodass der Nutzer eine Schnittstelle statt eines Netzwerks erreicht. Ein Full-Tunnel-Client trägt, was seine Routen und Filterregeln auswählen, was eine viel größere Fläche ist. Die beiden nach Protokollstärke zu vergleichen, verfehlt den Unterschied darin, was ein Angreifer durch sie erreichen kann. Das eine exponiert eine Anwendungsschnittstelle, das andere ein geroutetes Netzwerk, und beide verlangen unterschiedliche Prüfungen.

Fragen Sie, welcher Dienst exponiert ist, welche Operationen autorisiert sind und worauf das Gateway selbst lauscht. Eine Verwaltungsschnittstelle, die unter derselben Adresse wie das Nutzerportal erreichbar ist, ist ein Deployment-Befund, und keine Protokollwahl gleicht das aus.

Anwendungsbezogener Umfang verengt die Fläche weiter und ändert auch das Fehlerverhalten, wenn der Tunnel wegbricht. Ein Design, das Full-Tunnel-Erreichbarkeit annimmt, bricht auf Arten, die ein Per-App-Design nicht kennt, und die Supportlast folgt.

Fehlerausgang und Lebenszyklus entscheiden

Was geschieht, wenn Authentifizierung oder Schutz nicht verfügbar sind, ist eine Richtlinienentscheidung, die in die Prüfung gehört. Ein blockierter Ausgang und ein unangekündigter direkter Rückfall haben unterschiedliche Folgen, und der Unterschied ist in einer Funktionsliste unsichtbar. Nennen Sie das beabsichtigte Verhalten neben der Ressource, die es schützt.

Nehmen Sie den Patch- und Support-Lebenszyklus des Gateways auf, seine aktivierten externen Funktionen und den Update-Pfad für Clients. Eine korrekte Protokollwahl macht einen schlecht aufgestellten Dienst nicht sicher, und die meisten Vorfälle liegen in dieser Lücke und nicht in der Suite.

Schreiben Sie die fünf Felder, die Fehlerrichtlinie und den Eigentümer des Lebenszyklus auf eine Seite. Diese Seite ist eine Prüfung; ein Vergleich von Protokollfamilien ist eine Meinung.