Migration von IPSec-Lösungen zu SSL-Lösungen

Posted by HOB Marketing Mon, 15 Jun 2009 11:34:00 GMT

VPN (Virtual Private Network) wurde früher mit dem IPSec Protokoll (Internet Protocol Security) realisiert. Neuere Lösungen basieren auf SSL (Secure Sockets Layer). Die Lösungen mit SSL können analog zu IPSec Lösungen eingesetzt werden, mit SSL gibt es aber auch Lösungen die vom Prinzip her anders sind als IPSec Lösungen.

In diesem Dokument werden die Unterschiede und Vorteile von SSL gegenüber IPSec erörtert. Dieses Dokument befasst sich ausschließlich mit Lösungen für den Remote Zugriff von Laptops oder PCs.

Im Bereich von Gateway zu Gateway Verbindungen, welche beispielsweise bei der Anbindung von Außenstellen eingesetzt werden, macht SSL keinen Sinn so dass hier weiterhin IPSec eingesetzt wird.

Auch haben Geräte wie das Apple iPhone oder Handies mit Microsoft Windows mobile standardmäßig einen IPSec Client eingebaut, die Vorteile von SSL treffen hier nicht zu, so dass es hier meist keinen Sinn macht IPSec durch SSL zu ersetzen.

Dieses Dokument ist gegliedert in folgende Abschnitte:

  1. Wo kann man SSL einsetzen, aber IPSec funktioniert nicht

  2. Architektur von Systemen mit IPSec bzw. SSL

  3. Komprimierung bei IPSec bzw. SSL

  4. Streaming mit IPSec bzw. SSL

1. Wo kann man SSL einsetzen, aber IPSec funktioniert nicht

1.1. nur Zugriff über TCP Port 80 und 443 möglich

Bereiche des Internets wie in Firmen, Hotels oder Wi-Fi Hotspots sind regelmäßig durch Firewalls vom public Internet abgeschirmt. Weil aber generell ein Zugriff aus den abgeschirmten Bereichen möglich sein soll, vorwiegend für die Benutzung des Web-Browsers, sind in den Firewalls Zugriffe über den HTTP TCP Port 80 und den HTTPS TCP Port 443 erlaubt.

Ist in der Firewall nichts anderes konfiguriert so kann IPSec überhaupt nicht verwendet werden.

1.2. Proxies in Firmen-Netzwerken für den Zugriff aufs Public Internet

In vielen Firmen oder Organisationen werden Proxies eingesetzt welche den Zugriff auf das Public Internet regeln. Verwendet werden dabei die Protokolle Socks4/5 und HTTP. Alle gängigen Browser unterstützen den Zugriff über solche Proxies.

Proxies die hier eingesetzt werden sind z.B. Microsoft ISA Server oder Squid (Open-Source). In den Proxies kann verlangt werden dass sich ein Benutzer bzw. ein Gerät authentifiziert bevor es Zugriff auf das Public Internet erhält.

Für die Authentifizierung werden optional verwendet Userid/Passwort, NTLM oder auch Kerberos.

Es ist möglich in solchen Proxies die eingehenden Web-Seiten (HTTP / HTML) auf Viren zu checken. Mit entsprechenden konstruktiven Merkmalen ist es möglich beliebige Daten über diese Viren-Checker zu bekommen; man bekommt auch Viren darüber aber eben nicht mit dem Web-Browser sondern nur mit SSL-Clients.

Mit IPSec kann man solche Proxies generell nicht benutzen, nur mit TCP bzw. SSL ist der Zugriff möglich.

1.3. SSL über den HTTP TCP Port 80

Es gibt auch Installationen, vor allem in Hotels, wo nur Port 80 offen ist, nicht aber der HTTPS/SSL-Port 443. Es ist aber prinzipiell möglich, SSL-Daten über Port 80 zu schleusen, so dass auch hier der Zugriff mit dem Web-Browser bzw. mit SSL Clients möglich ist.

1.4. Kosten für den Internet-Zugriff in Hotels

Es wurde uns berichtet in manchen Hotels gibt es unterschiedliche Preismodelle für den Internet-Zugriff. Es gibt kostenlosen oder günstigen Zugriff über TCP Port 80 / 443 (da kann man SSL verwenden), will man aber IPSec verwenden so muss man ein anderes Preismodell wählen (teuerer).

1.5. preisgünstige Netzwerk-Komponenten

Z.B. wenn User von Zuhause aus eine VPN-Verbindung in die Zentrale aufbauen möchten dann soll in der Regel der Standard-DSL-Anschluss verwendet werden. In der Regel werden hier DSL-Router eingesetzt die auch NAT machen. Uns wurde berichtet bei solchen DSL-Router kann oft kein IPSec eingesetzt werden, oft auch nicht einmal mit NAT-Traversal.

2. Architektur von Systemen mit IPSec bzw. SSL

2.1. Architektur von Systemen mit IPSec

IPSec Lösungen sind in der Regel so aufgebaut dass am Client ein Treiber installiert wird. Dieser installiert im System einen sogenannten virtuellen Adapter. In der Regel kommt aus der Zentrale die INETA welche zur Kommunikation mit den Anwendungen in der Zentrale verwendet wird. Der Treiber im System fängt alle (oder die betreffenden) IP-Pakete ab, verschlüsselt diese und sendet die Pakete über den IPSec-Tunnel in die Zentrale. Pakete aus der Zentrale gehen den umgekehrten Weg. Es gibt auch IPSec-Lösungen mit Komprimierung.

2.2. Problematik von Treibern

Moderne Betriebssysteme sind so designed dass ein fehlerhaftes Programm weder das Betriebssystem zum Absturz bringen kann noch andere Programme stören oder beschädigen kann. Dies wird dadurch erreicht dass eben nur das Betriebssystem kritische Aktionen wie Input/Output oder Speicherverwaltung durchführen darf.

Benötigen Programme solche Aktionen so springen sie über sogenannte APIs ins Betriebssystem, das Betriebssystem prüft ob die Aktion fehlerfrei durchgeführt werden kann und dann führt das Betriebssystem im Auftrag der Anwendung die kritischen Aktionen durch.

Nun kann aber ein Betriebssystem eben von Hause aus nicht alles, dafür gibt es Treiber, Erweiterungen des Betriebssystems.

Treiber dürfen prinzipiell alle Aktionen ausführen, eben auch die kritischen und gefährlichen. Dies ist notwendig weil sonst ja Anwendungen nur das machen könnten was das standardmäßige Betriebssystem vorsieht.

Aus diesen Umständen ergeben sich mehrere Problematiken. Zum einen können fehlerhafte Treiber das gesamte Betriebssystem zum Absturz bringen, bei Windows spricht man dann von einem "blue screen". Beim Absturz des Betriebssystems hat man oft Datenverlust und es stört den Anwender sehr weil er eben ziemlich lange nicht arbeiten kann, eben so lange bis das Betriebssystem neu gebootet hat.

Für Treiber gibt es jeweils im Betriebssystem bestimmte Schnittstellen. Betriebssysteme entwickeln sich fort so dass auch diese Schnittstellen immer wieder verändert werden müssen. Das bedeutet meist dass man für jede Betriebssystem-Version einen bestimmten Treiber benötigt, der aber bei einer neueren Betriebssystem-Version nicht mehr funktioniert.

Bei normalen Anwendungen gibt es diese Problematik nicht weil die Hersteller bei der Entwicklung der Betriebssysteme darauf achten dass die Schnittstellen zu den Anwendungen (APIs) konstant gehalten werden.

Zur Entwicklung von Treiber braucht man qualifizierte Entwickler, solche sind selten. Und im Vergleich zu normalen Anwendungen sind Treiber viel schwieriger und aufwändiger zu entwickeln, debuggen und zu testen.

Zum Abschluss ist zu sagen dass die überwiegende Anzahl von Betriebssystem-Abstürzen ("blue screen") eben nicht Fehler des Betriebssystems selbst sind sondern eben von Treibern.

Microsoft hat mit Windows XP die Funktion Windows Error Reporting (WER) eingeführt. Dadurch wird Online Crash Analysis (OCA) möglich. Wenn Windows abstürzt und ein blue screen erscheint dann wird ein kleiner Core-Dump erzeugt der nach Nachfrage beim Benutzer zu Microsoft gesendet wird. Microsoft war damals sehr erstaunt über die vielen eingehenden Core-Dumps, die große Anzahl hatte man nicht erwartet. Bei der Auswertung der empfangenen Core-Dumps hat dann Microsoft festgestellt dass fehlerhafte Treiber 85% der Probleme ausmachten, der kleinere Rest waren echte Windows Kernel Probleme. Hat man weniger Treiber im System dann hat man entsprechend weniger Ärger und Probleme.

2.3. voller Netzwerk-Zugriff über SSL

Bei einigen SSL-Lösungen gibt es auch den vollen Netzwerk-Zugriff über SSL, analog zu Lösungen mit IPSec. Bei Standard-Lösungen hier wird wieder ein Treiber im Betriebssystem des Clients installiert, analog zu IPSec.

Bei HOB RD VPN mit dem PPP Tunnel hat man in einem neuartigen und zum Patent angemeldeten Verfahren vollen Netzwerk-Zugriff ohne Treiber, ohne Administrator-Rechte und ganz ohne Installation am Client. Die Lösung PPP Tunnel im HOB RD VPN ist Browser-basiert.

Weil bei dieser Lösung alles in der DMZ in der Zentrale installiert ist, und eben nichts am Client, sind Updates der Software viel einfacher durchzuführen was auch erheblich Kosten einspart.

2.4. Zugriff vom Web-Browser des Clients über ein SSL-VPN auf Web-Server in der Zentrale

Eine der ersten und somit grundlegenden Funktionen von SSL-VPNs war der Zugriff nur über den Web-Browser im Client. Greift ein Benutzer zu, so authentifiziert er sich zuerst am SSL-Gateway und hat dann Zugriff auf alle Web-Server in der Zentrale. Dieser Zugriff kann gegebenfalls eingeschränkt durch die Konfiguration des SSL-VPNs; der Benutzer kann dann nur auf vorbestimmte Web-Server zugreifen.

Die Kommunikation zwischen den Client (Web-Browser) und dem VPN-Gateway ist dann SSL-verschlüsselt bzw. HTTPS, zwischen dem VPN-Gateway und den internen Web-Servern über normales HTTP bzw. bei Bedarf wieder über HTTPS bzw. SSL; man spricht dann von Client-side SSL. Diese Funktion klingt relativ simpel, ist aber doch aufwändig weil im VPN-Gateway alle Links in den Web-Seiten umgerechnet werden müssen. Das ist prinzipiell möglich für:

 - HTML
 - CSS
 - Javascript, jscript
 - Ajax

Bei Web-Seiten mit folgendem Inhalt gibt es aber Einschränkungen und generell Probleme:

 - Active-X
 - Flash
 - Silverlight
 - Java

Zusätzlich kann man über den Browser auch Files mit der Zentrale austauschen, und zwar in beide Richtungen. Nicht alle SSL-VPNs beherrschen diese aufwändigen Verfahren zur Umrechnung von Web-Seiten oder zum Austausch von Files.

Bei HOB RD VPN heißt diese Funktion Web Server Gate. Der Austausch von Files heißt Web File Access. Zum einen werden in vielen Firmen vorwiegend oder grundsätzlich nur Web-Applikationen entwickelt bzw. eingesetzt, zum anderen braucht man eben am Client nur den normalen Web-Browser. Deshalb wird diese Art des Zugriffs über SSL-VPNs sehr oft eingesetzt. Bei IPSec VPNs gibt es keine vergleichbaren Funktionen.

2.5. Umleitung von TCP Datenstrom zu localhost

Ein der Basis-Funktionen von SSL-VPNs ist folgende: auf dem Client wird ein kleiner Proxy gestartet, diese wurde vorher als Java-Applet oder als ActiveX-Control von SSL-VPN heruntergeladen. Nun kann man auf dem Client die gewohnten Applikationen starten, diese verbinden sich dann aber nicht direkt zu dem jeweiligen Server sondern es geht erst mal über localhost zum lokalen Proxy. Dazu muss natürlich die Anwendung etwas anders konfiguriert werden.

Der lokale Proxy verschlüsselt die Daten dann per SSL und sendet diese zum VPN-Gateway. Das VPN-Gateway packt die Daten wieder aus und sendet diese zum gewünschten Ziel bzw. Server. Diese Funktion heißt bei HOB Universal Client, ansonsten wird oft von Port-Forwarding gesprochen. Diese Lösung hat gewisse Einschränkungen und funktioniert nur wenn die Client-Applikation ein TCP-Verbindung zum Server aufbaut; umgekehrt ist keine TCP Verbindung möglich wenn diese der Server zum Client aufbauen möchte. UDP kann man ebenfalls nicht verwenden.

Probleme gibt es auch wenn im in den TCP-Daten IP-Adressen übermittelt werden, was z.B. bei FTP oder RDP der Fall ist. Auch bei SIP und RTP werden in den Daten-Paketen IP-Adressen übermittelt, aber hier wird über UDP kommuniziert und Umleitung über localhost ist prinzipiell nicht möglich.

Bei Arbeiten mit lokalem Proxy kann mit RDP für den Windows Terminal Server das Session-Directory nicht verwendet werden weil der RDP Datenstrom eben über einen lokalen Proxy umgeleitet wird.

Beim HOB RD VPN ist SSL direkt im RDP Java Remote Desktop Client HOBLink JWT und im WebSecureProxy realisiert so dass auch hier die Funktion Session-Directory unterstützt wird, anders als bei Lösungen mit lokalen Proxies und Umleitung über localhost.

Die Funktion mit lokalen Proxies und Umleitung über localhost ist genügend in vielen Fällen, bietet aber keinen vollen Netzwerk-Zugriff. Der volle Netzwerk-Zugriff ist in vielen Fällen auch gar nicht erwünscht.

3. Komprimierung bei IPSec bzw. SSL

3.1. Komprimierung bei IPSec

In vielen IPSec-Lösungen ist Komprimierung eingebaut, nach unterschiedlichen Verfahren, meist aber deflate. Bei IPSec werden die Pakete einzeln komprimiert, ein eventuell verwendetes Dictionary muss bei jedem Paket zurückgesetzt werden. Dies geschieht aus dem Grunde weil IPSec ein Protokoll vom Typ connection-less ist. Das bedeutet, Pakete können verloren gehen, es können sich Pakete überholen oder Pakete können mit falscher Checksum beim Empfänger ankommen und dann verworfen werden. Auch werden von Routern in der Übertragungsstrecke Pakete verworfen wenn die Übertragungsstrecke überlastet ist; das ist ein ganz normaler Vorgang der auch bei allen IP-Stacks entsprechend berücksichtigt ist.

IPSec merkt nicht wenn Pakete nicht beim Empfänger ankommen, diese Problematik wird in den höheren Layers behandelt, z.B. im TCP-Stack. Durch die Tatsache dass bei IPSec bei jedem Paket das Dictionary zurückgesetzt wird ist die Komprimierung wenig wirkungsvoll.

Pakete sind bei IPSec meist klein, MTU = Maximum Transmission Unit oder auch Maximum-Receive-Unit (MRU) ist z.B. bei PPP nach RFC 1661 1.500 Bytes. Bei so kleinen Paketen ist keine gute Komprimierung möglich.

Inzwischen gibt es ab Gigabit-Ethernet Jumbo-Packets, bis 16.000 Bytes, da wäre eine bessere Komprimierung möglich, aber bei WAN kann man bisher keine so großen Pakete austauschen.

3.2. Komprimierung bei SSL

SSL ist connection-oriented, also kann hier effizient Komprimierung eingesetzt werden. Web-Browser beherschen z.B. das Komprimierungs-Verfahren zLib. Dies wird im HTTP-Header angegeben. Der Web-Browser selbst sendet keine komprimierten Daten, die Pakete vom Web-Browser zum Web-Server sind ja in der Regel ziemlich klein. Aber der Web-Server (oder ein SSL-Gateway mit der Funktion Web Server Gate) kann die Antwort mit zLib komprimieren und dadurch werden Web-Seiten entsprechend schneller geladen.

Im HOB RD VPN Web Server Gate ist Komprimierung mit zLib eingebaut. Web-Seiten können komprimiert werden auch wenn der ursprüngliche Web-Server die Daten unkomprimiert sendet.

Bei SSL wird durch ein entsprechendes Verfahren die verwendete Cypher-Suite ausgehandelt, das heißt welche Verschlüsselungs-Algorithmen verwendet werden.

Die Firma Netscape hat ursprünglich SSL erfunden und dabei vorgesehen dass beim Aushandeln der Cypher-Suite auch ein Komprimierungs-Algorithmus ausgehandelt werden kann. Deshalb hat HOB in der entsprechenden SSL-Suite eingebaut dass auch Komprimierung verwendet wird, das funktioniert aber nur wenn sowohl am Client als auch am VPN-Gateway die HOB SSL-Suite eingesetzt wird. Es sind außer HOB keine anderen Hersteller bekannt die auf SSL-Ebene komprimieren.

Wird bei HOB RD VPN der PPP-Tunnel mit Komprimierung eingesetzt, und es werden beispielsweise mit dem Windows Explorer Dateien ausgetauscht so findet hier eine wirkungsvolle Komprimierung statt. In der Praxis wurde beobachtet dass der Datenstrom manchmal bis auf 20% herunterkomprimiert wurde. Der Austausch der Dateien geht dann viel schneller, eben so wie mit einer virtuell fünf mal schnelleren Leitung.

4. Streaming mit IPSec bzw. SSL

Applikationen wie Video oder Audio verwenden Streaming, es wird ein kontinuierlicher Datenstrom gesendet. Ein Sonderfall von Streaming ist Real-Time wie z.B. VoIP = Voice over IP. Damit wir die Eignung von IPSec bzw. SSL für Streaming verstehen wollen wir zuerst die Grundlagen betrachten.

4.1. Übertragungsfehler

Wenn Daten übertragen werden können diese Daten durch physikalische Effekte verfälscht werden. Deshalb werden in den Daten-Paketen Prüfsummen eingebaut. Der Sender erzeugt die Prüfsummen und der Empfänger eines Daten-Pakets vergleicht dann ob die Prüfsummen noch stimmen; wenn nicht wird das Daten-Paket verworfen. Eine andere Möglichkeit hat der Empfänger nicht, der Absender im Daten-Paket kann ja auch verfälscht worden sein und deshalb kann der Empfänger den Absender nicht benachrichtigen.

4.2. Überlauf in Routern

Das Internet-Protokoll, kurz IP, ist connection-less. Nehmen wir an wir haben einen Router an den zwei Datenleitungen angeschlossen sind, eine schnelle Leitung 1 und eine langsame Leitung 2. Wenn jetzt der Router in schneller Folge Pakete von Leitung 1 empfängt die er auf Leitung 2 weitersenden soll so kann der Router diese Pakete nicht so schnell über die langsamere Leitung 2 weitersenden. Ein Lösung für dieses Problem ist dass der Router eben diese Pakete zwischenspeichert und dann die Pakete verzögert senden. Aber der Speicher eines Routers ist endlich und deshalb verwerfen Router die Daten-Pakete wenn sie mehr empfangen als die weitersenden können.

4.3. Das Protokoll UDP

Das Protokoll UDP = User Datagram Protocol ist sehr einfach. Ein Sender sendet Pakete, wenn diese Pakete beim Empfänger ankommen ist es gut, wenn nicht passiert auch nichts weiter. Im UDP Protokoll ist nichts eingebaut dass ein Sender irgendwie merkt dass die gesendeten Daten-Pakete nicht angekommen sind.

4.4. Das Protokoll TCP

Das Protokoll TCP = Transmission Control Protocol ist connection-oriented und komplex. Bei TCP ist sichergestellt dass alle Daten-Pakete die eine Anwendung versendet unversehrt, komplett und in der richtigen Reihenfolge beim Empfänger ankommen.

Vereinfacht dargestellt funktioniert das so: Wenn der IP-Stack eines Rechners ein TCP-Paket versenden dann muss der Empfänger innerhalb einer gewissen Zeit (ein Bruchteil einer Sekunde) eine Bestätigung erhalten. Empfängt der sendende IP-Stack keine Bestätigung, entweder weil das gesendete Paket verloren ging, der Empfänger gar nicht mehr lebt oder auch weil die Bestätigung verloren ging, so wiederholt der sendende IP-Stack dieses Paket. Wenn nach einer gewissen Anzahl von Wiederholungen immer noch keine Bestätigung gekommen ist so meldet der IP-Stack diesen Fehler an die Anwendung.

4.5. Eignung von UDP bzw. TCP für Streaming

Für Streaming, insbesondere Real-Time, verwendet man in der Regel UDP, nicht TCP. Wenn ab und zu ein Paket bei Streaming verloren geht ist das kein großes Problem. Wenn aber wie bei TCP durch Wiederholungen von Paketen das Streaming nicht kontinuierlich funktioniert dann ist das ein gewisses Problem.

4.6. Eignung von IPSec bzw. SSL für Streaming

IPSec ist wie UDP connection-less, Pakete werden vom IPSec-Layer nicht wiederholt, und deshalb ist IPSec gut geeignet für Streaming.

SSL basiert auf TCP. Bei SSL ist konstruktiv eingebaut dass alle Pakete bei Empfänger unversehrt, komplett und in der richtigen Reihenfolge eintreffen müssen, ansonsten funktioniert die Kryptographie von SSL nicht.

SSL ist deshalb weniger gut für Streaming geeignet. Ein Ausweg aus diesem Problem ist parallel zu SSL eine verschlüsselte UDP-Verbindung aufzubauen und dann die Streaming-Daten auf diesem Wege zu versenden, wenn möglich. Genau das ist in der HOB-Lösung VoIP HOBPhone eingebaut.

4.7. Erfahrungen aus der Praxis

Streaming über IPSec funktioniert gut. In der Regel funktioniert Streaming über SSL genauso gut weil Übertragungsfehler heutzutage relativ selten vorkommen.

Quellen:

Microsoft
DEVELOPING DRIVERS WITH THE WINDOWS DRIVER FOUNDATION
Penny Orwick, Guy Smith
ISBN-13: 978-0-7356-2374-3
ISBN-10: 0-7356-2374-0

02.05.09 KB
04.05.09 KB
12.06.09 KB

keine Kommentare |

You must be registered in order to write comments. To register as a new user click here.

If you're already registered, please leave a comment here

Leave a comment


emplates.arcsin.se/'), link_to("Frédéric de Villamil", 'http://fredericdevillamil.com')) %>
Powered by typo