© Kenneth Keifer, 123RF.com

Dass zwei Protokolle, die letztlich zum gleichen Ziel führen, nicht zwingend in Feindschaft zueinander stehen, beweisen Open VPN und IPsec seit Jahren. Obwohl es sich um konkurrierende VPN-Lösungen handelt, haben beide ihre Daseinsberechtigung und kommen gut miteinander zurecht.

Zwischen “das Rad nicht neu erfinden” und “es sollte immer Alternativen geben” klafft bisweilen eine große Lücke. Immer wieder machen sich Projekte mit sehr ähnlichen Zielsetzungen gegenseitig Konkurrenz. Missverständnisse, Meinungsverschiedenheiten und Streit um Details lösen Forks aus, die manchmal nur der Eitelkeit oder Verbohrtheit einzelner Akteure geschuldet sind.

Virtuell, privat, friedfertig

Andrerseits gibt es Projekte mit sehr ähnlichem Aufgabengebiet, die jahrelang überaus friedlich nebeneinander existieren. Im Bereich der virtuellen privaten Netzwerke trifft das voll und ganz auf die beiden beliebtesten Vertreter Open VPN [1] und die Linux-Implementierung von IPsec [2] zu. Zwar sind die beiden Projekte intern komplett anders gestrickt – von IPsec gibt es eine stattliche Anzahl Forks, von Open VPN keinen einzigen – doch letztlich geht es den Entwicklern beider Umgebungen einfach darum, sichere Datenübertragung in unsicheren Netzen zu ermöglichen.

Obwohl die beiden Projekte bisweilen identische Aufgaben erfüllen und daher immer wieder in Konkurrenz geraten, hat es zwischen den Projekten nie eine nennenswerte Fehde gegeben – die tobte eher innerhalb der IPsec-Welt. Vielleicht liegt das auch daran, dass viele Nutzer sogar auf beide Technologien angewiesen sind, weil sie beispielsweise privat auf Open VPN setzen, doch für den Zugang zum Netzwerk des Arbeitgebers oder Kunden den De-facto-Standard IPsec benötigen.

Ein langer Weg: IPsec

Die Geschichte der beiden könnte unterschiedlicher kaum sein. Das IPsec-Protokoll hat bereits zwei Jahrzehnte auf dem Buckel, allerdings dauerte es recht lange, bis Linux-Implementierungen zu haben waren. Zurück geht die Technologie unter anderem auf das von John Ioannidis 1993 vorgestellte Software IP Encryption Protocol (Swipe). Diese Kooperation von AT&T und der Columbia University diente dem Ziel, Onlineverbindungen besser abzusichern.

Das Internet stellte Interessierte damals vor zwei gravierende Probleme: Authentizität als auch Vertraulichkeit waren schwer sicherzustellen. Das berühmte Beispiel von Alice und Bob kennt fast jeder, und Swipe war so etwas wie der erste Schritt auf dem Weg hin zu sicherer Kommunikation. Das Protokoll konnte Verbindungen verschlüsseln, sodass Angreifer sich nicht mehr ohne Weiteres in den Datenstrom einklinken und ihn mitlesen konnten. Mechanismen zur Authentifizierung der Gegenseite implementierte Swipe jedoch nur rudimentär.

Gauntlet: IPsec-Firewall

Der US-Amerikaner Wei Xu setzte die von Ioannidis begonnene Arbeit fort, und so konnte sein damaliger Arbeitgeber, Trusted Information Systems, 1995 erstmals eine Firewall mit der Unterstützung für abgesicherte Verbindungen mit dem Namen Gauntlet auf den Markt bringen. Die dort genutzte Technik war letztlich jene, die die Internet Engineering Task Force später als IPsec in Form diverser RFCs standardisierte, erstmals 1998 im RFC 2401 [3].

John Ioannidis hatte bereits ein Jahr vorher mit einer Implementierung des Standards für Linux begonnen. Weil in den USA damals noch sehr strenge Richtlinien für den Export kryptographischer Software galten, tat er dies, während er sich im Ausland aufhielt. John Gilmore machte 1997 ein eigenes Projekt aus dem Code und gab ihm den Namen Free Secure Wide-Area Networking, kryptisch abgekürzt: Free S/WAN [4].

Für zwei Jahre war Freeswan die quasi-offizielle IPsec-Umsetzung für Linux [5]. Doch Zeit seines Lebens kämpfte das Projekt mit extremen Ansichten seines Gründers Gilmore. Ein Streitpunkt war etwa die Tatsache, dass Gilmore sich weigerte, auch nur Patches von US-Staatsbürgern zu akzeptieren. Ken Bantoft platzte 2000 der Kragen, er forkte Freeswan als “Super Freeswan” und akzeptierte nahezu alle ausstehenden Patches, darunter auch viele von US-Bürgern.

Red Hat will mitmischen

Nicht nur Ken Bantoft machte John Gilmore unmissverständlich klar, was er von dessen Umtrieben hielt – auch von Red Hat kam laute Kritik: Dort hatte der Entwickler David Miller ebenfalls begonnen IPsec für Linux zu bauen, in erster Linie, weil Red Hat den betroffenen Code als Teil des Linux-Kernels sehen wollte. Obendrein betrachtete man dort die ganze Diskussion eher als akademisch, weil ein Stück Code, das nicht von US-Bürgern gewartet werden könnte, es nicht in den Kernel schaffen würde.

Das Problem des Crypto-Exports durch US-Bürger hing bis 2002 über der IPsec-Community. Ein Wissenschaftler namens Daniel J. Bernstein hatte schon 1995 – noch als Student – die US-Regierung verklagt, weil er der Meinung war, die Regulierung des Exportes kryptographischer Software sei ein Verstoß gegen die US-Verfassung. 2002, nach mehreren Gerichtsverfahren, wandte sich die US-Regierung schließlich von ihrer bis dahin vertreteten Rechtsmeinung ab, was die Linux-Community mehrheitlich als Erfolg wertete. Die US-Regierung habe eingelenkt und es sei somit kein Problem mehr, Kryptosoftware aus den USA zu exportieren, lautete die Interpretation.

Der Startschuss: Bernstein gegen die USA

Ab da ging es in der IPsec-Community rund: Ausgehend von Freeswan entstanden in kurzer Zeit zwei Forks, Openswan [6] und Strongswan (Abbildung 1, [7]), die beide bis heute aktiv sind. Freeswan selbst veröffentlichte 2003 die letzte Version und wird seither nicht mehr gepflegt. Im November 2011 entstand aus Openswan sogar ein weiterer Fork, Libreswan [8], ebenfalls aufgrund unterschiedlicher Ansichten der Entwickler.

Abbildung 1: Die IPsec-Konfiguration für Strongswan auf Debian birgt zahlreiche komplizierte Parameter.

Die drei Projekte Openswan, Strongswan und Libreswan werden nach wie vor gepflegt und erscheinen regelmäßig; technisch liegen sie nicht so weit voneinander entfernt, dass sich die Unterschiede als epochal bezeichnen ließen. Strongswan erfreut sich des guten Rufes, eine umfassende und sehr genaue Dokumentation zu haben, während die Openswan-Dokumentation meist nicht in besonders gutem Licht steht.

Letztlich ist es aber vor allem eine Frage der persönlichen Präferenz, welchen Stack ein Admin verwendet. Auch die Benutzerzahlen und die Anzahl der Committer geben kein geeignetes Auswahlkriterium ab. Alle drei Ipsec-Projekte verweisen auf Nachfrage auf Tausende Downloads und ein Core-Team von unter zehn Entwicklern. Dass selbst ein akademisch geprägtes Projekt wie Strongswan mit hohem Anspruch an Qualität und Sicherheit (wie fast alle Open-Source-Projekte) ohne Entwicklungsmodell auskommt und von nur schätzungsweise acht Committern betrieben wird, überrascht aber doch.

IPsec gilt also als Pionier für VPN-Verbindungen. Im Grunde nichts anderes als die Kombination verschiedener IP- und Verschlüsselungstechniken, ist es sehr flexibel und bietet viele verschiedene Konfigurationsparameter. Doch mit dieser Flexibilität ging und geht auch immer ein sehr hohes Maß an Komplexität einher, die Nicht-Geeks an der Einrichtung einer IPsec-Verbindung zwischen zwei Hosts scheitern lässt.

Wer schon mal ein IPsec-basiertes Netzwerk für ein Unternehmen aufgesetzt hat, schlimmstenfalls mit einer proprietären Implementierung auf einer Seite ([9], [10]), kennt dieses Problem sicher. Noch interessanter wird es, wenn die kommerziellen Stacks verschiedener Netzwerk-Hardwarehersteller ins Spiel kommen: Eine Cisco-Kiste per IPsec mit Linux zu verheiraten bringt Admins an die Grenze der Belastbarkeit.

Dass flächendeckende Verbindungssicherheit mit IPsec nicht realisierbar ist, merkte der Amerikaner James Yonan 2003. Anstatt sich über das Problem zu beklagen, fing er an, eine Lösung zu erarbeiten. Seine Idee: Anders als IPsec sollte seine VPN-Software ohne größere Schwierigkeiten in Betrieb zu nehmen sein, vor allem sollte sie auf einem simplen Server-Client-Prinzip beruhen und obendrein SSL verwenden. Im April 2004 veröffentlichte Yonan seine Software unter dem Namen Open VPN 1.1.0.

Einfach sicher: Open VPN

Open VPN [1] machte so einiges einfacher: Nach der Installation des Open VPN-Servers ist es in der Regel völlig ausreichend, VPN-Benutzer anzulegen und die eigenen Zertifikate für die Nutzer auszurollen (siehe Abbildung 2). Mit dynamischen IPs hat Open VPN ebenso wenig Probleme wie mit Verbindungen durch Firewalls, Proxys oder NAT-Gateways. Im Vergleich zum hakeligen IPsec, das fürs NAT-Traversal ein eigenes Plugin brauchte, kam das einer Revolution gleich.

Obendrein zeigt Open VPN, dass die Arbeit auch bei gutem Umgangston gelingen kann. James Yonan scheint ein sehr umgänglicher Mensch zu sein, denn auch neun Jahre nach der ersten öffentlichen Version ist immer noch kein Fork in Sicht. Eine Google-Suche führt lediglich zu einer E-Mail auf der Open-VPN-Mailingliste, in der einer der etwa zwanzig Entwickler sich nach einer längeren Abwesenheit James Yonans fragte, ob der überhaupt noch lebe. Weit und breit keine Spur einer sich anbahnenden Spaltung.

Der Erfolg gibt dem Projekt indes Recht: Open-VPN-Clients stehen für die gängigen Betriebssysteme samt und sonders zur Verfügung, auch Server sind auf den meisten Plattformen problemlos zu betreiben. Auf Android gibt es seit einiger Zeit einen nativen Open-VPN-Client mit allen wichtigen Features, ebenso für I-OS (siehe Abbildung 3). Yonan konnte Open VPN sogar als Grundlage für eine eigene Firma [11] nutzen und verdient heute mit Open-VPN-Tunneln, einfachem Zertifikatsmanagement, Support und Entwicklung Geld.

Abbildung 2: Open VPN macht es richtig vor: Ab Werk sind nur wenige Variablen zu ändern, dann steht der Tunnel.

Abbildung 3: Open VPN ist mittlerweile weit verbreitet, auch mit Android ist die Verbindung kein Problem (im Bild: Cyanogenmod).