Entmystifizierung der Bedrohungen in verschlüsselten Tunneln: Was Sie wissen müssen

Veröffentlicht: November 2023. Aktualisiert: August 2026. Geprüft vom PKI-Beratungsteam von Encryption Consulting.

Ein verschlüsselter Tunnel macht den Datenverkehr nicht unsichtbar oder unangreifbar, sondern lediglich die Nutzdaten für jeden ohne den passenden Schlüssel unlesbar. Diese Unterscheidung ist wichtig, da die meisten Angriffe auf Tunnel die Verschlüsselung selbst nicht knacken. Sie zielen vielmehr auf die Aushandlung, das Zertifikat, den Schlüssel oder den Endpunkt auf einer der beiden Seiten des Tunnels ab. Dieser Leitfaden erläutert die aktuellen Bedrohungen für VPN-, TLS-, Mutual-TLS- (mTLS) und SSH-Tunnel, die Auswahl des richtigen Protokolls für den jeweiligen Anwendungsfall und wie ein sicheres Schlüsselmanagement-Programm für die Zeit nach der Quantencomputer-Ära aussehen sollte.

Was sind verschlüsselte Tunnel und was genau schützen IPsec, TLS und SSH?

Ein verschlüsselter Tunnel ist ein logischer Kanal, der den Datenverkehr verschlüsselt und in der Regel auch authentifiziert, bevor er ein nicht vertrauenswürdiges Netzwerk durchquert. Dadurch sieht jeder, der die Pakete abfängt, den verschlüsselten Text und kann ihn nicht unbemerkt fälschen oder wiedergeben. Vier Tunnelfamilien decken nahezu alle Unternehmenseinsätze ab, und jede basiert auf unterschiedlichen Akronymen, die es wert sind, vorab definiert zu werden:

• IPsec (Internet Protocol Security) mit IKEv2 (Internet Key Exchange Version 2)VPN ist ein in RFC 7296 definierter VPN-Standard der Netzwerkschicht, der Sicherheitsassoziationen (SAs) aushandelt und neu verschlüsselt und anschließend IP-Pakete verschlüsselt. Er ist der Standard für Site-to-Site-VPNs und für die meisten Remote-Access-Bereitstellungen von Behörden und Netzbetreibern.
• WireGuardWireGuard ist ein modernes, minimalistisches VPN-Protokoll, das auf einer festen, vordefinierten Verschlüsselungssuite (Curve25519, ChaCha20-Poly1305, BLAKE2s) basiert und im WireGuard-Whitepaper dokumentiert ist. Es verzichtet auf einen Aushandlungsschritt der Verschlüsselung, wodurch ein ganzes Risiko von Downgrades eliminiert wird, allerdings auf Kosten der algorithmischen Flexibilität.
• TLS-Tunnel (Transport Layer Security) und mTLS (Mutual TLS)TLS 1.3, spezifiziert in RFC 9846 (der RFC 8446 ersetzt), sichert die Transportschicht für HTTPS, TLS-VPN-Clients und Service-Mesh-Datenverkehr. Bei mTLS legen sowohl Client als auch Server Zertifikate vor, sodass die Tunnelidentität gegenseitig und nicht einseitig ist. Daher bildet mTLS die Grundlage der meisten Zero-Trust- und Machine-to-Machine-Architekturen.
• SSH-Tunnel (Secure Shell)Portweiterleitung über eine SSH-Sitzung, häufig verwendet für administrativen Zugriff, Jump-Hosts und Bastion-Architekturen. Die Sicherheit hängt ausschließlich von der Host-Schlüsselverifizierung und dem Lebenszyklus der verwendeten SSH-Schlüssel ab, nicht von einer Zertifizierungsstelle.

Zwei Eigenschaften entscheiden darüber, ob ein Tunnel langfristig vertrauenswürdig bleibt: Perfect Forward Secrecy (PFS), das sicherstellt, dass selbst die Aufzeichnung des heutigen Datenverkehrs und der Diebstahl des morgigen privaten Schlüssels vergangene Sitzungen nicht offenlegen, und das Schlüsselmanagement, das die Ausstellung, Rotation und den Widerruf von Zertifikaten, Pre-Shared Keys (PSKs) und SSH-Schlüsseln regelt. Alles Weitere in diesem Artikel baut auf diesen beiden Konzepten auf.

Welche Bedrohungen zielen tatsächlich auf verschlüsselte Tunnel ab?

Verschlüsselte Tunnel werden an den Rändern angegriffen, nicht in der Mitte: Die Aushandlung, die Identitätsprüfung, der Endpunkt und die Metadaten sind die Orte, an denen die eigentlichen Vorfälle auftreten. Die sieben unten aufgeführten Vektoren sind für die überwiegende Mehrheit der tunnelbezogenen Sicherheitslücken und Warnungen verantwortlich.

• Man-in-the-Middle-Angriffe (MitM). Ein Angreifer positioniert sich zwischen den beiden Tunnelendpunkten, um den Datenverkehr abzufangen oder zu manipulieren. Der Lenovo-Superfish-Vorfall von 2014 verdeutlichte dies: Vorinstallierte Adware ersetzte unbemerkt vertrauenswürdige Zertifikate durch eigene, sodass der TLS-Tunnel des Browsers sicher erschien, während ein zwischengeschalteter Server jede Sitzung mitlas. Starke gegenseitige Authentifizierung und Certificate Pinning schließen diese Sicherheitslücke.
• Downgrade-Angriffe. Ein Angreifer erzwingt bei der Aushandlung den Rückgriff auf eine schwächere Protokollversion oder eine leichter zu knackende Verschlüsselungssuite. Der ALPACA-Angriff (Brinkmann et al., 2021) ist ein aktuelles Beispiel: Er nutzt TLS-Server aus, die ein Zertifikat für mehrere Anwendungsprotokolle gemeinsam nutzen, und leitet die HTTPS-Anfrage eines Browsers an einen unabhängigen SMTP-, IMAP- oder FTP-Dienst um, der dasselbe Zertifikat verwendet. Die Verhinderung von Downgrades in IKEv2 und die Entfernung veralteter Aushandlungspfade in TLS 1.3 (RFC 9846) sind direkte Gegenmaßnahmen.
• Aushandlung schwacher Verschlüsselungssuiten. Wenn ein Tunnel noch Diffie-Hellman-Verschlüsselungen der Exportklasse, RC4 oder kurze DH-Gruppen zulässt, kann ein Angreifer diese Schwachstelle ausnutzen. Die Logjam-Schwachstelle von 2015 demonstrierte genau dies bei TLS-Servern, die noch 512-Bit-Diffie-Hellman-Verschlüsselungen der Exportklasse erlaubten. RFC 9325 enthält aktuelle, konkrete Richtlinien, welche TLS- und DTLS-Verschlüsselungssuiten und -gruppen noch akzeptabel sind.
• Kompromittierung von Schlüssel oder Zertifikat. Der Tunnel ist nur so vertrauenswürdig wie der dahinterliegende private Schlüssel und das Zertifikat. Ein gestohlener CA-Schlüssel, ein nicht widerrufenes, abgelaufenes Zertifikat oder ein durchgesickerter Pre-Shared Key ermöglicht es einem Angreifer, einen Endpunkt vollständig zu imitieren. Deshalb Automatisierung des Zertifikatslebenszyklus und HSM unterstützt die Schlüsselaufbewahrung, die für die Tunnelsicherheit von größerer Bedeutung ist, als die meisten Teams annehmen.
• Verkehrsanalyse und Fingerprinting. Selbst ohne die Entschlüsselung eines einzigen Bytes können Paketgröße, Timing und Datenflussmuster Aufschluss darüber geben, welche Website oder Anwendung sich hinter einem TLS- oder VPN-Tunnel befindet – eine Technik, die in zahlreichen Studien zum Website-Fingerprinting dokumentiert wurde. Padding, Deckverkehr und konsistente Tunnelnutzungsmuster reduzieren dieses Risiko, können es aber nie vollständig eliminieren.
• Fehlkonfiguration des Split-Tunnelings. Wenn nur ein Teil des Datenverkehrs durch den verschlüsselten Tunnel geleitet wird und der Rest direkt ins Internet gelangt, kann ein kompromittiertes Gerät zu einer Brücke zwischen dem öffentlichen Internet und dem internen Netzwerk werden, das das VPN eigentlich schützen sollte. Aus diesem Grund heben Frameworks wie CMMC SC.L2-3.13.7 Split-Tunneling ausdrücklich als Kontrollpunkt hervor, der eine dokumentierte, risikobasierte Entscheidung erfordert und keine Standardeinstellung darstellt.
• Jetzt sammeln, später entschlüsseln (HNDL) gegen Tunnelverkehr. Angreifer zeichnen heute verschlüsselte VPN- oder TLS-Sitzungen auf, um sie mit Hilfe eines kryptografisch geeigneten Quantencomputers zu entschlüsseln. Langlebige, sensible Daten (z. B. aus den Bereichen Verteidigung, Gesundheitswesen und Finanzen), die heute über IPsec oder TLS erfasst werden, sind genau die Art von Daten, die HNDL anvisiert. NIST FIPS 203 (ML-KEM) und die IKEv2-Erweiterungen für den hybriden Schlüsselaustausch in RFC 9370 und RFC 8784 wurden speziell entwickelt, um diese Sicherheitslücke zu schließen.

Die Kompromittierung des Endpunkts des Tunnels verdient besondere Erwähnung. Die CISA-Empfehlung AA24-060B dokumentierte, wie staatliche Akteure die Sicherheitslücken CVE-2023-46805 (eine Authentifizierungsumgehung) und CVE-2024-21887 (eine Command-Injection-Schwachstelle) gegen Ivanti Connect Secure und Policy Secure VPN-Gateways ausnutzten, um sich initialen Zugriff zu verschaffen – lange bevor die Verschlüsselung im Tunnel selbst zum Tragen kam. Die Lehre daraus ist in allen Vorfällen dieselbe: Der Tunnelendpunkt muss wie jedes andere internetfähige Gerät gepatcht werden, da Angreifer die Verschlüsselung in der Regel umgehen, anstatt sie zu durchbrechen.

Welches Tunnelprotokoll sollten Sie für einen bestimmten Anwendungsfall wählen?

Wählen Sie IPsec/IKEv2 für Site-to-Site-VPNs und regulierte Umgebungen, die FIPS-validierte, herstellerübergreifende Konfigurationen erfordern; WireGuard für Fernzugriff und Cloud-native Bereitstellungen, bei denen Leistung und eine minimale Angriffsfläche wichtig sind; TLS/mTLS für Anwendungsschicht- und Dienst-zu-Dienst-Datenverkehr, der bereits über HTTPS und Service-Mesh-Infrastruktur läuft; und SSH-Tunnel für administrativen Zugriff und Jump-Host-Zugriff, jedoch nicht als universellen VPN-Ersatz. Die folgende Tabelle erläutert die jeweiligen Vor- und Nachteile.

Protokoll	Typischer Anwendungsfall	Schlüsselmanagementmodell	Relative Leistung	Optimale Bildschirmwahl
IPsec / IKEv2	Site-to-Site-VPN, Regierungs- und Betreibernetzwerke	X.509-Zertifikate oder PSKs, IKEv2-SA-Neuschlüsselung	Moderate Kernel-Implementierungen sind schnell, der Verhandlungsaufwand ist jedoch höher.	Regulierte Umgebungen mit mehreren Anbietern, die FIPS-validierte Modi benötigen
WireGuard	VPN-Fernzugriff, Cloud- und Container-Netzwerke	Statische oder rotierte Curve25519-Schlüsselpaare, keine integrierte PKI	Hohe, kleine Codebasis und feste Verschlüsselungssuite minimieren den CPU-Overhead.	Leistungsempfindlicher Fernzugriff und Mesh-Netzwerk
TLS-Tunnel / mTLS	API-Traffic, Service Mesh, Zero-Trust-Workload-Identität	Kurzlebige X.509-Zertifikate, die von einer privaten Zertifizierungsstelle ausgestellt werden.	Hoch mit TLS 1.3, Sitzungswiederaufnahme reduziert die Handshake-Kosten	Anwendungsschicht- und Maschine-zu-Maschine-Authentifizierung
SSH-Tunnel	Administratorzugriff, Bastion-Hosts, Portweiterleitung	SSH-Schlüsselpaare und Hostschlüssel, typischerweise ohne Tools nicht verwaltet	Hohe Kapazität für den Tunnel selbst, begrenzt durch sitzungsbasierte Skalierung	Bedienerzugriff und sichere Ad-hoc-Weiterleitung, nicht Massendatentransport

Wie härtet man die Bereitstellung eines verschlüsselten Tunnels ab?

Die Absicherung eines verschlüsselten Tunnels ist ein wiederholbarer Prozess und keine einmalige Konfigurationsänderung. Führen Sie diese Schritte bei jeder neuen Bereitstellung eines IPsec-, WireGuard-, TLS- oder SSH-Tunnels durch.

1. Wählen Sie das Protokoll anhand der obenstehenden Entscheidungstabelle entsprechend dem tatsächlichen Anwendungsfall und den Compliance-Anforderungen aus und nicht anhand dessen, was bereits installiert ist.
2. Deaktivierung veralteter Verhandlungspfade: IKEv1, TLS 1.0 und 1.1 sowie alle Cipher Suites, die nicht auf der aktuellen empfohlenen Liste gemäß RFC 9325 stehen.
3. Erzwingen Sie die gegenseitige Authentifizierung, wo immer der Anwendungsfall es zulässt, X.509-Zertifikate für IPsec und mTLS, verifizierte Host-Schlüssel für SSH, damit eine kompromittierte Netzwerkposition allein keinen Endpunkt imitieren kann.
4. Kurzlebige Zertifikate ausstellen und Pre-Shared Keys sowie SSH-Schlüssel nach einem festgelegten Zeitplan rotieren, idealerweise durch automatisiertes Zertifikatslebenszyklusmanagement anstatt durch manuelle Erneuerung.
5. Bestätigen Sie, dass Perfect Forward Secrecy standardmäßig aktiviert ist (Diffie-Hellman- oder ECDHE-Schlüsselaustausch pro Sitzung), sodass eine zukünftige Schlüsselkompromittierung den bisherigen Datenverkehr nicht offenlegen kann.
6. Dokumentieren und beschränken Sie Split-Tunneling explizit, indem Sie den gesamten Datenverkehr durch den Tunnel leiten, es sei denn, eine spezifische, risikobewertete Ausnahme wird genehmigt und protokolliert.
7. Patchen Sie die Tunnelterminierungs-Appliance oder -Software im gleichen Rhythmus wie jedes andere mit dem Internet verbundene System und abonnieren Sie die Hersteller- und CISA-Empfehlungen für dieses Produkt.
8. Aktivieren Sie die zentrale Protokollierung und Überwachung von Tunnelaufbau, Schlüsselerneuerungsereignissen und fehlgeschlagenen Authentifizierungsversuchen, um Aufklärungsversuche zu erkennen, bevor es zu einem Sicherheitsvorfall kommt.
9. Fügen Sie einen hybriden Post-Quantum-Key-Exchange hinzu, sofern die Plattform dies unterstützt (RFC 9370 für IKEv2 oder eine hybride ML-KEM TLS 1.3-Gruppe), für jeden Tunnel, der Daten mit einer mehrjährigen Vertraulichkeitsanforderung transportiert.

Welche Kompromisse hinsichtlich Leistung und Interoperabilität bestehen zwischen diesen Protokollen?

WireGuard und TLS 1.3 bieten im Allgemeinen geringere Latenz und höheren Durchsatz als klassische IPsec/IKEv1-Konfigurationen. IPsec/IKEv2 bleibt jedoch die sicherere Standardlösung, wenn strikte Interoperabilität zwischen verschiedenen Anbietern oder FIPS-validierte Verschlüsselungsmodi nicht verhandelbar sind. Die feste Verschlüsselungssuite von WireGuard ist sowohl ein Sicherheitsvorteil (keine Downgrade-Möglichkeit) als auch eine Einschränkung der Interoperabilität, da sie nicht auf die vom Peer unterstützte Technologie herunterskaliert werden kann. Dies schließt WireGuard gelegentlich für ältere Netzwerkhardware aus. TLS 1.3 und mTLS profitieren in unterstützten Konfigurationen von Session Resumption und 0-RTT, was bei API-Skalierung relevant ist. Jedes zusätzliche Zertifikat in einem Service Mesh erhöht jedoch den Aufwand für Ausstellung und Rotation, der automatisiert werden muss, um die Verwaltung zu gewährleisten. SSH-Tunnel skalieren schlecht für den Transport großer Datenmengen, da jede weitergeleitete Verbindung eine Sitzung belegt. Daher eignen sie sich eher für administrative Zugriffspfade als als Ersatz für produktive VPNs. In jedem Fall erhöht das Hinzufügen eines hybriden Post-Quantum-Key-Exchange die Größe des Handshakes und die CPU-Kosten etwas. Die aktuellen NIST-Richtlinien betrachten diesen Mehraufwand angesichts des damit verbundenen HNDL-Risikos als akzeptabel.

Welche Schlüsselmanagementabhängigkeiten bestimmen, ob ein Tunnel sicher bleibt?

Die maximale Sicherheit eines verschlüsselten Tunnels wird durch seine schwächste Schlüsselverwaltungsmethode bestimmt, nicht durch seine Verschlüsselungssuite. Vier Abhängigkeiten sind dabei besonders wichtig:

• Zertifikatslebenszyklus für TLS, mTLS und IPsec. Abgelaufene Zertifikate verursachen Ausfälle, und nicht widerrufene gestohlene Zertifikate verursachen Sicherheitslücken. Eine Plattform für den verwalteten Zertifikatslebenszyklus wie beispielsweise CertSecure Manager Die Ausstellung, Verlängerung und der Widerruf werden automatisiert, sodass kurzlebige Zertifikate operativ realisierbar werden und keine manuelle Belastung darstellen – eine Disziplin, die angesichts der sinkenden Lebensdauer öffentlicher TLS-Zertifikate gemäß dem in [Referenz einfügen] beschriebenen Zeitplan immer wichtiger wird. PKI im Jahr 2026: Wie man die 47-tägige Ära der TLS-Zertifikate übersteht.
• Rotation des vorab geteilten Schlüssels für IPsec und WireGuard. Ein PSK, der nie rotiert, verhält sich wie ein permanentes Passwort. Behandeln Sie PSKs mit der gleichen Rotationsdisziplin wie alle langlebigen Anmeldeinformationen und bevorzugen Sie die zertifikatbasierte Authentifizierung, sofern die Plattform dies unterstützt.
• SSH-Schlüsselverwaltung. Im Gegensatz zu Zertifikaten haben SSH-Schlüssel kein Ablaufdatum, was dazu führt, dass sich in unkontrollierten Umgebungen über Jahre hinweg verwaiste Schlüssel mit dauerhaftem Zugriff ansammeln. Eine zentrale Verwaltung und Rotation der SSH-Schlüssel behebt dieses Problem.
• Bereitschaft nach der Quantenbeschleunigung (PQC). NIST FIPS 203 (ML-KEM) ist der finale Standard für die Post-Quantum-Key-Kapselung. IETF RFC 9370 und RFC 8784 definieren, wie der hybride Post-Quantum-Key-Austausch bereits heute in IKEv2 integriert werden kann, ohne auf einen vollständigen IPsec-Ersatz warten zu müssen. Jeder Tunnel, der Daten transportiert, die über Jahre vertraulich bleiben müssen – beispielsweise Gesundheitsdaten, Verteidigungskommunikation oder langfristige Finanzdaten – sollte jetzt auf den hybriden Key-Austausch umgestellt werden, da die HNDL-Erfassung bereits stattfindet. Eine vollständige Anleitung finden Sie hier: Post-Quantum-VPN-Migration: IPsec-, TLS-VPNs und Fernzugriff für die Firmware-Bereitschaft der Geräte und einen schrittweisen Einführungsansatz.

Der Speicherort dieser Schlüssel ist ebenso wichtig wie die Häufigkeit ihrer Rotation. Root- und ausstellende CA-Schlüssel sowie die vorab geteilten Schlüssel hinter hochsensiblen IPsec-Tunneln eignen sich besonders für die hardwarebasierte Speicherung im Rahmen einer HSM-as-a-Service -Bereitstellung anstelle einer softwarebasierten Schlüsselspeicherung.

Wie sehen reale verschlüsselte Tunnelinstallationen aus?

Vier gängige Bereitstellungsmuster veranschaulichen, wie diese Protokolle und wichtigen Managementpraktiken in der Praxis zusammenwirken.

• Fernzugriff für Unternehmen. Ein Workforce-VPN-Konzentrator beendet IKEv2- oder WireGuard-Sitzungen von verwalteten Laptops, authentifiziert Benutzer anhand einer zertifikatsbasierten Geräteidentität, die über eine verwaltete PKI ausgestellt wird, und erzwingt vollständiges Tunneling (kein Split-Tunneling) für jede Sitzung, die regulierte Daten berührt.
• Standortvernetzung. Zwei Rechenzentren oder ein Rechenzentrum und eine Cloud-VPC verbinden sich über einen IPsec/IKEv2-Tunnel mit X.509-Zertifikatsauthentifizierung anstelle eines statischen PSK, mit automatischer Zertifikatserneuerung und einem dokumentierten Rekey-Intervall.
• Service Mesh und Microservices. Jeder Dienstaufruf innerhalb eines Kubernetes-Clusters läuft über mTLS, wobei kurzlebige Workload-Zertifikate (oft Minuten bis Stunden) automatisch von einer internen Zertifizierungsstelle ausgestellt werden, sodass ein kompromittierter Pod nicht unbemerkt einen anderen Dienst imitieren kann.
• Administrativer Bastion-Zugang. Die Ingenieure greifen über einen SSH-Tunnel auf einen gehärteten Bastion-Host zu, wobei die Host-Key-Verifizierung erzwungen, die Sitzungsaufzeichnung aktiviert und die SSH-Schlüssel zentral ausgegeben und rotiert werden, anstatt ad hoc auf einzelnen Laptops generiert zu werden.

Einschränkungen

• Verschlüsselung schützt die Vertraulichkeit und, bei ordnungsgemäßer Authentifizierung, die Integrität der Datenübertragung. Sie schützt jedoch nicht vor einem kompromittierten Endpunkt, einem böswilligen Insider mit legitimen Tunnelzugriffen oder einer anfälligen Anwendung, die hinter dem Tunnel läuft.
• Die Analyse des Datenverkehrs und die Erstellung von Fingerprints können durch kein derzeitiges Tunnelprotokoll vollständig eliminiert, sondern nur durch Padding, Deckverkehr und konsistente Nutzungsmuster reduziert werden.
• Der hybride Post-Quantum-Schlüsselaustausch für IKEv2 (RFC 9370, RFC 8784) erfordert die Unterstützung durch beide Endpunkte. Daher ist in Umgebungen mit unterschiedlichen Herstellern oder Legacy-Systemen möglicherweise eine schrittweise Einführung anstelle einer einmaligen Umstellung erforderlich.
• Die feste Verschlüsselungssuite von WireGuard kann nicht für regulatorische Rahmenbedingungen neu verhandelt werden, die spezifische, separat validierte Algorithmen vorschreiben, was in einigen staatlichen Kontexten weiterhin IPsec/IKEv2 oder TLS begünstigt.
• Keiner der oben genannten Hinweise ersetzt eine vollständige Architekturprüfung; spezifische regulatorische, vertragliche oder Bedrohungsmodellanforderungen können die richtige Antwort für eine bestimmte Organisation verändern.

Was würde Encryption Consulting empfehlen?

Unsere Beratungsteams beobachten bei Tunnel-bezogenen Vorfällen immer wieder dasselbe Muster: Die Kryptografie ist wirksam, das Schlüsselmanagement oder die Endpunkt-Patching jedoch nicht. Drei Maßnahmen schließen diese Lücke weitgehend. Erstens: Die Verwaltung des Zertifikatslebenszyklus für alle TLS-, mTLS- und IPsec-Zertifikate sollte auf einer zentralen, automatisierten Plattform wie dem CertSecure Manager erfolgen. Dadurch wird die Erneuerung zu einem fehleranfälligen, manuellen Vorgang, und der Widerruf erfolgt sofort, sobald der Verdacht besteht, dass ein Schlüssel kompromittiert wurde. Zweitens: Root- und ausstellende CA-Schlüssel sowie alle wichtigen IPsec-PSKs sollten in hardwarebasierter HSM-as-a-Service -Verwahrung gespeichert werden , anstatt sie in Software zu belassen. Neue PKI-Implementierungen sollten auf PKI-as-a-Service standardisiert werden , sodass die Zertifikatsausstellung für VPN- und mTLS-Anwendungsfälle von Anfang an konsistent und auditierbar ist. Drittens: Der SSH-Tunnelzugriff sollte als eigenständiger Zugangstyp behandelt werden und nicht vernachlässigt werden. SSH Secure sollte verwendet werden , um SSH-Schlüssel analog zur Zertifikatsverwaltung zu inventarisieren, zu rotieren und zu sperren.

Zur Frage der Quantencomputertechnologie ist unsere Position eindeutig: Das Sammeln und spätere Entschlüsseln von Daten stellt kein zukünftiges Risiko für den Tunnelverkehr dar, sondern ein akutes für jede Organisation, die Daten mit mehrjähriger Vertraulichkeitsanforderung verarbeitet. Erstellen Sie zunächst ein kryptografisches Inventar der Tunnel, die diese Art von Daten transportieren, und testen Sie anschließend den hybriden ML-KEM-Schlüsselaustausch auf einem nicht kritischen Pfad, bevor Sie ihn flächendeckend einführen.

Fazit

Verschlüsselte Tunnel gehören nach wie vor zu den effektivsten Kontrollmechanismen zum Schutz von Daten während der Übertragung, und keine der hier beschriebenen Bedrohungen spricht gegen deren Einsatz. Vielmehr plädieren sie dafür, den Tunnel als Teil eines größeren Systems zu betrachten: ein für den jeweiligen Anwendungsfall ausgewähltes Protokoll, eine Authentifizierung, die nicht herabgestuft werden kann, Schlüssel und Zertifikate, die planmäßig und nicht zufällig rotiert werden, ein Endpunkt, der wie jedes andere internetfähige System regelmäßig aktualisiert wird, und eine Roadmap für die Zeit nach der Quantencomputer-Ära, die jetzt beginnt und nicht erst nach der ersten Veröffentlichung im Zusammenhang mit HNDL. Werden diese fünf Punkte beachtet, ist die Verschlüsselung selbst nicht länger die Schwachstelle.

Häufig gestellte Fragen

Reicht ein VPN aus, um einen Man-in-the-Middle-Angriff zu verhindern? Ein VPN reduziert das MitM-Risiko durch Verschlüsselung und Authentifizierung des Datenverkehrs zwischen zwei Endpunkten. Es schützt jedoch nicht vor MitM-Angriffen, die vor dem Aufbau des Tunnels erfolgen, wie beispielsweise eine kompromittierte Zertifizierungsstelle, ein gefälschter Authentifizierungsschritt oder Schadsoftware auf dem Endpunkt selbst. Daher sind Endpunkthygiene und Zertifikatsvalidierung neben dem VPN weiterhin wichtig.

Sollten wir IPsec durch WireGuard ersetzen? Nicht generell. WireGuard ist eine gute Wahl für leistungskritische Fernzugriffe und Cloud-native Netzwerke, aber IPsec/IKEv2 ist weiterhin die bessere Lösung, wenn FIPS-validierte Verschlüsselungsmodi, Interoperabilität zwischen verschiedenen Herstellern oder eine bestehende Carrier-Grade-Infrastruktur erforderlich sind. Die Entscheidung sollte sich daher am jeweiligen Anwendungsfall orientieren und nicht auf einer pauschalen Migration basieren.

Wie oft sollten VPN-Pre-Shared-Keys und -Zertifikate erneuert werden? Zertifikate für TLS, mTLS und IPsec sollten der gängigen Branchenpraxis mit kürzeren Gültigkeitsdauern und automatischer Verlängerung weit vor Ablauf entsprechen. Pre-Shared-Keys sollten nach einem festgelegten Zeitplan (üblicherweise alle 90 Tage oder weniger für wichtige Tunnel) erneuert werden, anstatt unbegrenzt statisch zu bleiben.

Spielt Post-Quanten-Kryptographie heute schon eine Rolle für VPNs oder ist sie ein zukünftiges Problem? Sie ist heute schon für jeden Tunnel relevant, der Daten überträgt, die jahrelang vertraulich bleiben müssen, denn Angreifer können verschlüsselte Sitzungen jetzt aufzeichnen und sie entschlüsseln, sobald Quantencomputer existieren, die die aktuelle Public-Key-Kryptographie knacken können. Dieser Ansatz, bekannt als „Ernten jetzt, Entschlüsseln später“, und der hybride Post-Quanten-Schlüsselaustausch für IKEv2 sind bereits in RFC 9370 und RFC 8784 standardisiert.

Was ist die häufigste Ursache für Sicherheitslücken in verschlüsselten Tunneln? Laut öffentlichen Vorfallsberichten verursachen ungepatchte Tunnelabschlussgeräte und falsch verwaltete Schlüssel oder Zertifikate mehr Sicherheitslücken als jede Schwäche in der zugrunde liegenden Kryptografie. Deshalb ist die Härtung der Endpunkte und die Automatisierung des Schlüssellebenszyklusmanagements genauso wichtig wie die Wahl des Protokolls.

Referenzen

• IETF, RFC 7296, Internet Key Exchange Protocol Version 2 (IKEv2): https://datatracker.ietf.org/doc/html/rfc7296
• IETF, RFC 9370, Mehrere Schlüsselaustausche im Internet Key Exchange Protocol Version 2 (IKEv2): https://datatracker.ietf.org/doc/html/rfc9370
• IETF, RFC 8784, Mischen von Pre-Shared Keys in IKEv2 für Post-Quantum-Sicherheit: https://datatracker.ietf.org/doc/html/rfc8784
• IETF/RFC Editor, RFC 9846, Das Transport Layer Security (TLS) Protokoll Version 1.3 (ersetzt RFC 8446): https://www.rfc-editor.org/rfc/rfc9846.html
• IETF, RFC 9325, Empfehlungen für die sichere Verwendung von Transport Layer Security (TLS) und Datagram Transport Layer Security (DTLS): https://datatracker.ietf.org/doc/html/rfc9325
• WireGuard, Kernel-Netzwerktunnel der nächsten Generation (Protokoll-Whitepaper): https://www.wireguard.com/papers/wireguard.pdf
• NIST, Special Publication 800 77 Revision 1, Guide to IPsec VPNs: https://csrc.nist.gov/pubs/sp/800/77/r1/final
• NIST, FIPS 203, Standard für modulgitterbasierte Schlüsselkapselungsmechanismen (ML-KEM): https://csrc.nist.gov/pubs/fips/203/final
• NIST, IR 8547 (erster öffentlicher Entwurf), Übergang zu Post-Quanten-Kryptographiestandards: https://nvlpubs.nist.gov/nistpubs/ir/2024/NIST.IR.8547.ipd.pdf
• CISA-Warnung AA24-060B, Bedrohungsakteure nutzen mehrere Schwachstellen in Ivanti Connect Secure und Policy Secure Gateways aus: https://www.cisa.gov/news-events/cybersecurity-advisories/aa24-060b
• Brinkmann et al., ALPACA: Protokollverwirrung auf Anwendungsschichtebene, Analyse und Minderung von Schwachstellen in der TLS-Authentifizierung: https://alpaca-attack.com/