Schaut man sich die Geschichte von IPsec an, dann fallen zwei Dinge auf: Es gibt drei Versionen, welche die jeweils vorherige obsolet machten. Die erste stammt aus dem Jahr 1995, die zweite aus dem Jahr 1998 und die dritte aus dem Jahr 2005. Der aktuelle Stand der Architektur stammt aus dem Dezember 2005. Einige Implementationsvorgaben in Bezug auf die Verwendung von Verschlüsselungsalgorithmen sind hingegen älter und wurden (noch) nicht angepasst.
Fakultativer Authentication Header seit 2005
Was die aktuelle Version von IPsec von der vorherigen Version unterscheidet ist der Wegfall der Pflicht zur Unterstützung des Authentication Header (AH). Für die Sicherheit des Netzwerkverkehrs zwischen zwei Punkten unterstützt IPsec zwei Sicherheitsprotokolle, Authentication Header (AH) und Encapsulating Payload (ESP). AH stellt Integrität und Datenursprung des Pakets sicher, während ESP die Nutzlast verschlüsselt und deren Integrität und Datenursprung sichert.
In der aktuellen Version von IPsec ist die Unterstützung und Verwendung des Authentication Headers fakultativ. Ohne AH bleibt aber der Header ungeschützt. Der Schutz gegen Spoofing und Insertions-Attacken ist weg.
Schutz des Headers
Nebst dem AH gibt es zwei andere technische Möglichkeiten, den Header effizient zu schützen. Die eine ist der Einbezug des Headers in die Additional Data eines AEAD-Cipher wie AES-GCM. Bei einer AEAD-Cipher können nebst der verschlüsselten Nutzlast zusätzliche Daten authentisiert werden. Integrität und Datenursprung des Headers können so einfach und effizient sichergestellt werden. Die andere Möglichkeit ist die Erweiterung der Abdeckung des Integritätsschutzes und der Datenursprungsbestätigung auf den Header. Das funktioniert zum Beispiel. in der Kombination von AES-CBC mit SHA512.
Es gibt nur ein Problem: Die IETF RFCs zur Verwendung von AES-GCM und SHA2 schliessen eine solche Abdeckung aus. Die historische Ursache: Beide RFCs wurden vor der Veröffentlichung der aktuellen Version von IPsec geschrieben und veröffentlicht, als der Authentication Header noch Pflicht war.
Das Problem mit Authentication Header
AH bringt gleich in zwei Bereichen Nachteile mit sich: Der Verarbeitung und dem Overhead. Für das, was sich technisch ohne zusätzlichen Overhead lösen liesse, generiert AH einen Overhead von 28 Bytes pro Paket. Zusätzlich braucht es mehr Verarbeitungsschritte, da es für den AH eine eigene Security Association (SA) braucht und das Sicherheitsprotokoll vor der Verschlüsselung und nach der Entschlüsselung der Nutzlast ausgeführt wird. Aufgrund der Ineffizienz ist es durchaus nachvollziehbar, dass die meisten Anbieter von Sicherheitsprodukten und Produkten mit IPsec-Funktionalität den AH nicht mehr unterstützen. Dadurch ergeben sich aber auch zusätzliche Angriffsvektoren, die ausgenützt werden können.
Grundregeln der Netzwerkverschlüsselung
Im Bereich der Netzwerkverschlüsselung ist der beste Schutz derjenige, der soviel verschlüsselt wie möglich und so viele Teile des Pakets oder Frames wie möglich mit Integritätsschutz und Datenursprungbestätigung versieht. Nur die Felder, die sich während des Transports ändern dürfen können nicht mit Integritätsschutz kombiniert mit Datenursprungsbestätigung versehen werden.
Network Address Translation (NAT) führt dazu, dass sich gewisse Adressfelder während des Transports ändern können. Es gibt Anbieter, die es erlauben, den durch die Authentisierung zu schützenden Bereich zu definieren und in Felder aufzuteilen. Damit lassen sich Felder, die sich während dem Transport ändern dürfen, von der Authentisierung aussparen.
Unterschiede in den IP-Netzwerken
Nicht jedes IP-Netzwerk verändert ein Feld des Headers während des Transports. Bei IP-Netzwerken kommt es darauf an, ob es sich um IPv4 oder IPv6 handelt, um welche Art von Adressen es sich handelt und ob es sich um statische oder dynamische Verbindungen handelt. Zusätzlich kommt es drauf an, ob NAT verwendet wird und wann die Verschlüsselung erfolgt.
Das Problem mit der Industrie
Die Industrie gibt sich dynamisch und fortschrittlich. Das ist Marketing. Die IETF gibt sich sicherheitsorientiert und zeitgemäss. Leider ist die IETF – übrigens gleich wie die NIAP – herstellerhörig. Nicht die Sicherheit steht im Fokus, sondern die Industrieinteressen. Die Wahl der zu authentisierenden Felder des Headers findet sich deshalb weder in IETF RFCs noch in den Produkten der volumenmässigen Marktführer.
Für die Industrie im Allgemeinen scheint es einfacher, den Entwicklungsaufwand zu minimieren und die entsprechenden standardsetzenden Gremien in ihrem Interesse zu beeinflussen. Mit dem Kriterium "Interoperabilität" lässt sich Fortschritt vordergründig im Zaun halten.
IPsec ist unverzichtbar
IPsec als interoperable Sicherheitsarchitektur für IP-Netzwerke ist unverzichtbar. Das heisst allerdings nicht, dass die IPsec-Architektur und die Verwendung von Algorithmen auf dem Stand von 2005 eingefroren werden müssen.
Wie kann dies geändert werden?
Es liegt an mehreren Parteien, IPsec an die aktuellen Anforderungen und Möglichkeiten anzupassen: Den Anbietern, der IETF und den Kunden. Solange die Kunden sich nicht genau ansehen, was sie kaufen und welchen Schutz sie erhalten, sind sie mitschuldig an der derzeitigen Situation. Der Sicherheitsexperte Bruce Schneier hat dies sehr treffend formuliert: "Der Markt belohnt Time-to-Market, Leistung und Preis. Der Sicherheit und Langlebigkeit wird kaum Beachtung geschenkt. Dies ist ein Marktversagen".
WireGuard als Alternative
WireGuard www.wireguard.com ist mittlerweile eine etablierte Open-Source-Alternative zu IPsec, allerdings nur dort, wo sie unterstützt wird. Es wird standardmäßig mit dem Linux-Kernel und mit Android geliefert. Darüber hinaus gibt es Implementierungen für Windows, macOS, iOS und andere Betriebssysteme. WireGuard ist viel weniger komplex als IPsec und benötigt viel weniger Ressourcen. Anders als bei IPsec wird die zu verwendende Cipher Suite nicht ausgehandelt, sondern ist vorgegeben. Sie besteht aus Curve25519, ChaCha20, Poly1305, BLAKE2, SipHash24, HKDF und baut auf dem Noise-Protokoll-Framework auf. Es ist jedoch durchaus möglich, WireGuard mit einer anderen CIpher Suite wie
AES-GCM und einer beliebigen elliptischen Kurve zu betreiben. Eine Version mit russischen Chiffrierverfahren ist ebenfalls verfügbar:WireGuard selbst ist (noch) keine vollständige Lösung. Sowohl für die Verteilung der Authentifizierungsinformationen als auch für das Management wird - vor allem bei grösseren Installationen - zusätzliche Software benötigt, die als Open Source derzeit nur spärlich und mit eingeschränkter Funktionalität verfügbar ist. Wie bei IPSec gibt es aber auch hier kommerzielle Anbieter, die eine Komplettlösung anbieten, sowohl als Cloud-basiertes SaaS als auch als On-Premise-Version für den Unternehmenseinsatz. Das Problem mit dem unauthentisierten äusseren Header existiert allerdings auch bei WireGuard.
Andere Alternativen
Für IP-Netzwerke zwischen Standorten gibt es Lösungen, die nicht IPsec zur Verschlüsselung verwenden und daher nicht mit IPsec interoperabel sind. Andererseits lösen einige von ihnen die Sicherheit von IP-Netzen effizienter. Und was die Echtzeitverschlüsselung angeht, sind sie IPsec deutlich überlegen. Inzwischen gibt es Lösungen, die bis zu 100 Gb/sec Vollduplex in Echtzeit und beliebiger Paketgröße unterstützen. Einige Anbieter integrieren auch einen vollständigen DoS/DDoS-Schutz sowohl für die Datenebene als auch für die Steuerungsebene. Allerdings ist IPsec für die Interoperabilität mit IPsec erforderlich. Die Alternativen bilden jeweils ein geschlossenes System in sich.
Dieser Artikel erschien am 6. September 2019 auf Inside-IT. Dies ist eine aktualisierte Version.