Coloures-pic - Fotolia

SSL/TLS-VPN versus IPsec VPN: Wo liegen Vor- und Nachteile?

Nur wer die Besonderheiten von SSL/TLS-VPNs und IPsec-VPNs kennt, kann beurteilen, welche Variante die Anforderungen seines Unternehmens erfüllt. Wir bieten Hilfe beim Vergleich.

Wenn Ihr Unternehmen Probleme mit dem Management seines IPsec-VPNs hat, kann die Aussicht, clientlos zu arbeiten, durchaus attraktiv klingen – schließlich lassen sich SSL/TLS-basierte VPNs in der Regel viel einfacher implementieren und verwalten.

Entscheidend ist hierbei die Frage, wann man IPsec und wann man SSL/TLS verwenden soll. Diese lässt sich nicht unbedingt klar mit Ja oder Nein beantworten. Tatsächlich geht es in vielen Organisationen nicht um SSL/TLS-VPN versus IPsec-VPN, sondern um SSL/TLS-VPN und IPsec-VPN.

Sowohl IPsec- als auch SSL/TLS-VPNs können sicheren Fernzugriff für den Unternehmensbereich bieten, aber ihr Ansatz unterscheidet sich grundlegend. Diese Unterschiede wirken sich direkt auf die Anwendungs- und Sicherheitsservices aus und sollten die Basis für Bereitstellungsentscheidungen sein.

IPsec-VPNs schützen IP-Pakete, die zwischen entfernten Netzwerken oder Hosts und einem IPsec-Gateway ausgetauscht werden, das sich am Rand (Edge) Ihres privaten Netzwerks befindet. SSL/TLS-VPN-Produkte schützen Anwendungs-Traffic-Ströme von Remote-Nutzern zu einem SSL/TLS-Gateway. Anders ausgedrückt: IPsec-VPNs verbinden Hosts oder Netzwerke mit einem geschützten privaten Netzwerk. SSL/TLS-VPNs hingegen verbinden die Anwendungssitzung eines Benutzers sicher mit Diensten innerhalb eines geschützten Netzwerks.

IPsec-VPNs können alle IP-basierten Anwendungen unterstützen. Für eine Anwendung sieht ein IPsec-VPN genauso aus wie jedes andere IP-Netzwerk. SSL/TLS-VPNs können nur browserbasierte Anwendungen unterstützen, es sei denn, es gibt individuelle Anpassungen zur Unterstützung anderer Typen.

Bevor Sie sich für eine der beiden Varianten – oder beide – entscheiden, sollten Sie wissen, wie SSL/TLS- und IPsec-VPNs in puncto Sicherheit abschneiden und welchen Preis Sie für diese Sicherheit in Form von Verwaltungsaufwand zahlen müssen.

Nachfolgend vergleichen wir, wie IPsec- und SSL/TLS-VPNs die Authentifizierung und Zugriffssteuerung, die Abwehr von Angriffen und die Clientsicherheit realisieren. Dann sehen wir uns an, was erforderlich ist, um sowohl IPsec- als auch SSL/TLS-VPNs zu konfigurieren und zu administrieren. Dies umfasst die Vor- und Nachteile von clientbasierten und clientlosen VPNs sowie die Anpassung von VPN-Gateways an Ihr Netzwerk und Ihre App-Server.

Authentifizierung und Zugriffssteuerung

Eine anerkannte Best Practice im Bereich der Sicherheit ist es, nur den Zugriff zu erlauben, der explizit erwünscht ist, und alles andere zu verweigern. Dazu gehört einerseits die Authentifizierung, die sicherstellt, dass die kommunizierende Entität – sei es eine Person, eine Anwendung oder ein Gerät – diejenige ist, die sie vorgibt zu sein. Die Zugriffssteuerung wiederum ordnet eine Identität den zulässigen Aktionen zu und setzt diese Einschränkungen durch.

Authentifizierung

Sowohl SSL/TLS- als auch IPsec-VPNs unterstützen eine Reihe von Methoden zur Benutzerauthentifizierung. IPsec verwendet Internet Key Exchange (IKE) Version 1 oder Version 2, wobei digitale Zertifikate oder Pre-Shared Secrets für die Zwei-Faktor-Authentifizierung genutzt werden.

Pre-Shared Secrets ist die mit Abstand sicherste Methode zur sicheren Kommunikation, aber auch die verwaltungsintensivste. SSL/TLS-Webserver authentifizieren sich immer mit digitalen Zertifikaten, unabhängig davon, welche Methode zur Authentifizierung des Nutzers verwendet wird.

Sowohl SSL/TLS- als auch IPsec-Systeme unterstützen die zertifikatsbasierte Benutzerauthentifizierung, obwohl beide durch individuelle Anbietererweiterungen kostengünstigere Optionen ermöglichen. Die meisten SSL/TLS-Anbieter unterstützen Passwörter und Tokens als Erweiterungen.

SSL/TLS eignet sich besser für Szenarien, in denen der Zugriff auf Systeme streng kontrolliert wird oder in denen installierte Zertifikate nicht durchführbar sind. Das betrifft zum Beispiel Desktops von Geschäftspartnern, öffentliche Kiosk-PCs und Heimcomputer.

Zugriffssteuerung

Nach der Authentifizierung verlässt sich ein IPsec-VPN nicht auf Schutzmaßnahmen im VPN selbst, sondern auf solche im Zielnetzwerk, etwa Firewalls und Anwendungen für die Zugriffssteuerung. Die IPsec-Standards unterstützen jedoch Selektoren – Paketfilter, die den Traffic zu einzelnen Zielen oder Anwendungen zulassen, verschlüsseln oder blockieren. In der Praxis gewähren die meisten Organisationen Hosts Zugriff auf ganze Subnetze, anstatt sich die Mühe zu machen, Selektoren für jede IP-Adressänderung oder neue Anwendung zu erstellen und zu modifizieren.

SSL/TLS-VPNs werden in der Regel mit granulareren Zugriffssteuerungen eingesetzt, die am Gateway durchgesetzt werden. Dies bietet eine weitere Schutzebene, bedeutet aber auch, dass Administratoren an der Stelle mehr Zeit für die Konfiguration und Pflege von Richtlinien aufwenden. Da sie auf Session-Ebene arbeiten, können SSL/TLS-VPNs den Benutzer- oder Gruppenzugriff auf einzelne Anwendungen (Ports), ausgewählte URLs, eingebettete Objekte, Anwendungsbefehle und sogar Inhalte filtern und Entscheidungen darüber treffen.

Falls Sie wirklich eine Zugriffssteuerung pro Benutzer und pro Anwendung am Gateway benötigen, sollten Sie sich für SSL/TLS entscheiden. Wenn Sie vertrauenswürdigen Benutzergruppen einheitlichen Zugriff auf ganze private Netzwerksegmente geben müssen oder die höchste verfügbare Sicherheitsstufe mit Shared-Secret-Verschlüsselung benötigen, empfiehlt sich IPsec.

Abwehr von Angriffen

Sowohl SSL/TLS als auch IPsec unterstützen Blockverschlüsselungsalgorithmen, beispielsweise Triple DES, die häufig in VPNs verwendet werden. SSL/TLS-VPNs unterstützen zudem Stromverschlüsselungsalgorithmen, die oft für das Web-Browsing Anwendung finden. Bei vergleichbaren Schlüssellängen ist die Blockverschlüsselung weniger anfällig für Traffic-Analysen als die Stromverschlüsselung.

Wenn Sie ein SSL/TLS-VPN implementieren, wählen Sie Produkte, die die aktuelle Version von TLS unterstützen, die stärker ist als das ältere SSL. Neben anderen Vorteilen eliminiert TLS ältere Optionen für den SSL-Schlüsselaustausch und die Nachrichtenintegrität, die es anfällig für das Knacken und Fälschen von Schlüsseln machten.

Über die Verschlüsselung hinaus gibt es einige wichtige Unterschiede zwischen IPsec-VPNs und TLS-VPNs, die sich auf die Sicherheit, Performance und Funktionalität auswirken können. Dazu gehören:

  • Umgang mit MitM-Angriffen (Man in the Middle): Die Verwendung von Shared Secrets für die IPsec-Authentifizierung und -Verschlüsselung verhindert MitM-Angriffe vollständig. Außerdem erkennt und verweigert IPsec die Änderung von Paketen, was ebenfalls MitM-Attacken vereitelt, auch wenn keine Shared Secrets verwendet werden. Es kann zu Problemen führen, wenn sich zwischen den Endpunkten ein NAT-System (Network Address Translation) befindet.
    Schließlich liegt es in der Natur eines NAT-Gateways, Pakete zu modifizieren, indem es öffentliche IP-Adressen durch private ersetzt und Port-Nummern manipuliert. Allerdings unterstützen fast alle IPsec-Produkte NAT-Traversal-Erweiterungen.
    TLS verfügt über einige Schutzmechanismen gegen weniger gravierende MitM-Angriffe (die nicht die Verschlüsselung aushebeln). So überträgt es etwa Sequenznummern in verschlüsselten Paketen, um die Paketinjektion zu verhindern, und verwendet Nachrichtenauthentifizierung, um Payload-Änderungen zu erkennen.
  • Verhindern von Message Replay: IPsec wie auch TLS verwenden Sequenzierung, um Message-Replay-Angriffe zu erkennen und abzuwehren. IPsec ist effizienter, weil es Out-of-Order-Pakete weiter unten im Stack im Systemcode verwirft. In SSL/TLS-VPNs werden Out-of-Order-Pakete von der TCP-Session-Engine oder der TLS-Proxy-Engine erkannt und verbrauchen mehr Ressourcen, bevor sie verworfen werden. Das ist einer der Gründe, warum IPsec in der Regel für Site-to-Site-VPNs genutzt wird, bei denen es auf die reine Performance ankommt, um die Anforderungen an ein hohes Volumen und eine geringe Latenz zu erfüllen.
  • Resilienz gegenüber Denial of Service (DoS): IPsec ist widerstandsfähiger gegen DoS-Angriffe, da es auf einer unteren Netzwerkschicht arbeitet. TLS verwendet TCP und ist damit anfällig für TCP SYN Floods, die Sitzungstabellen mit Daten überfluten und viele Standardnetzwerk-Stacks lahmlegen. IPsec-VPN-Appliances in Business-Qualität sind gegen DoS-Angriffe gehärtet, und einige IPsec-Anbieter veröffentlichen sogar DoS-Testergebnisse.

Um die DoS-Anfälligkeit der jeweiligen Implementierung zu beurteilen, lohnt sich ein genauer Blick auf die einzelnen Produkte und die veröffentlichten Testergebnisse von unabhängigen Dritten. Dazu zählen die Zertifizierungen der International Computer Security Association (ICSAlabs) für IPsec, IKE und SSL/TLS.

Clientsicherheit

Ihr VPN, ganz gleich, ob IPsec oder SSL/TLS, ist nur so sicher wie die Laptops, PCs oder mobilen Geräte, die damit verbunden sind. Ohne Vorsichtsmaßnahmen lässt sich jedes Clientgerät dazu verwenden, Ihr Netzwerk anzugreifen. Deshalb sollten Unternehmen, die ein VPN gleichen welchen Typs implementieren, ergänzende Maßnahmen für die Clientsicherheit vorschreiben, etwa Personal Firewalls, Malware-Scans, Intrusion Prevention, OS-Authentifizierung und Dateiverschlüsselung.

Dies ist mit IPsec einfacher, da IPsec einen Softwareclient benötigt. Einige IPsec-VPN-Clients enthalten integrierte Desktop-Sicherheitsprodukte. So können nur Systeme das VPN nutzen, die den Sicherheitsrichtlinien des Unternehmens entsprechen.

SSL/TLS-Clientgeräte stellen in diesem Punkt eine größere Herausforderung dar, weil SSL/TLS-VPNs von Computern außerhalb der Kontrolle eines Unternehmens erreicht werden können – öffentliche Computer sind eine besondere Herausforderung. Die Anbieter haben verschiedene Antworten darauf, zum Beispiel:

  • Ein SSL/TLS-VPN kann versuchen, sicherzustellen, dass keine sensiblen Informationen von Sitzung zu Sitzung auf einem gemeinsam genutzten Computer übertragen werden. Zu diesem Zweck werden Informationen wie zwischengespeicherte Anmeldedaten und Webseiten sowie temporäre Dateien und Cookies gelöscht.
  • Ein SSL/VPN kann den Browser lokal ein Applet ausführen lassen, das nach offenen Ports sucht und überprüft, ob ein Malware-Schutz vorhanden ist, bevor das Gateway den Fernzugriff akzeptiert.
  • Einige SSL/TLS-VPNs kombinieren die Clientsicherheit mit Zugriffsregeln. Beispielsweise kann das Gateway einzelne Anwendungsbefehle filtern (etwa FTP GET zulassen, nicht aber FTP PUT, oder das Abrufen von HTTP-Objekten, die auf .exe enden, unterbinden), um den Aktionsradius derjenigen einzuschränken, die ungesicherte Computer nutzen.

Der Sitzungsstatus ist eher eine Frage der Benutzerfreundlichkeit als der Sicherheit. Aber es sollte nicht unerwähnt bleiben, dass sowohl IPsec- als auch SSL/TLS-VPN-Produkte oft konfigurierbare Keepalives ausführen, die erkennen, wenn der Tunnel nicht mehr existiert.

Beide Arten von Tunneln werden getrennt, wenn der Client die Netzwerkkonnektivität verliert oder es aufgrund von Inaktivität zu einem Timeout kommt. Je nach Position im Protokoll-Stack werden unterschiedliche Methoden verwendet, die aber letzten Endes den gleichen Effekt auf die Nutzer haben.

Abbildung 1: SSL/TLS-VPN und IPsec-VPN im Vergleich.
Abbildung 1: SSL/TLS-VPN und IPsec-VPN im Vergleich.

Mit oder ohne Client

Die Attraktivität von SSL/TLS-VPNs besteht vor allem darin, dass sie Standardbrowser als Clients für den Zugriff auf sichere Systeme verwenden, anstatt Clientsoftware installieren zu müssen. Doch es gibt eine Reihe von Faktoren zu berücksichtigen.

SSL/TLS-VPNs eignen sich hervorragend, wenn es darum geht, browserbasierte Apps für Remote-Geräte verfügbar zu machen. Generell gilt jedoch: Je vielfältiger der Anwendungsmix, desto attraktiver kann IPsec werden. Es läuft auf einen Kompromiss zwischen der Installation von IPsec-Clients und der Anpassung von SSL/TLS-VPNs hinaus.

Natürlich sind nicht alle Anwendungen browserfähig. Wenn dies wichtige Anwendungen betrifft, müsste das Gateway einen Desktop-Agenten, zum Beispiel ein Java-Applet, pushen, um den Zugriff zu ermöglichen – etwa auf einen Legacy-Client oder eine Serveranwendung.

Wenn es in der Umgebung viele solcher Anwendungen gibt, kann der Aufwand für die Entwicklung oder die Bereitstellung von Add-ons größer sein als bei der Unterstützung eines IPsec-VPNs. Beim Einsatz dieser Plug-ins kann es zu Konflikten mit anderen Sicherheitsrichtlinien für Desktops kommen.

Die meisten Organisationen blockieren zum Beispiel nicht signiertes Java, da es sich unter anderem nutzen lässt, um Trojaner zu installieren oder Dateien abzurufen beziehungsweise zu löschen. Einige Organisationen sperren alle aktiven Inhalte, um auf Nummer sicher zu gehen. Infolgedessen müssen Sie womöglich einige Browserclients neu konfigurieren, um ein SSL/TLS-VPN zu verwenden. Somit sind Sie wieder gezwungen, die Clientkonfigurationen zu modifizieren.

Die meisten Clientplattformen, darunter Windows, Mac OS X, Android und Apple iOS, besitzen native Unterstützung für IPsec. Einige Gateways benötigen für erweiterte Funktionen möglicherweise noch Clientsoftware von Drittanbietern, während ältere Clients vielleicht nicht über eine native Lösung verfügen. Achten Sie deshalb darauf, potenzielle VPNs unter diesem Aspekt zu bewerten. Die Installation von Drittanbieterclients ist zeitaufwendig und erfordert Zugriff auf die Geräte der Benutzer.

Einige Firmen bieten Hardware-IPsec-VPN-Clients für Organisationen an, die mit verschiedenen Betriebssystemplattformen arbeiten müssen. Diese kleinen Appliances werden zwischen den Heim-PC eines Mitarbeiters und das Kabel- oder DSL-Modem geschaltet und fungieren als IPsec-VPN-Client.

Dahinter steckt die Idee, im Vorfeld in Hardware zu investieren, um die Verwaltung des VPN-Zugangs über ein vom Unternehmen kontrolliertes Gerät zu ermöglichen, anstatt jedes Clientgerät dahinter separat zu administrieren. Stattdessen können Unternehmen IPsec-fähige Firewalls für Einzelbüros/Home-Office verwenden, um die LANs von Telearbeitern in ihre Site-to-Site-VPN-Topologie einzubinden.

Die Verteilung und Pflege von Richtlinien wird häufig durch die Mobilität der Benutzer und die unregelmäßige Konnektivität behindert. Dies ist ein ernsthaftes Problem für IPsec-VPNs. IPsec-Administratoren müssen Sicherheitsrichtlinien für jede autorisierte Netzwerkverbindung erstellen und dabei kritische Informationen wie IKE-Identität, Diffie-Hellman-Gruppe, Kryptoalgorithmen und Lebensdauer von Sicherheitszuordnungen ermitteln.

IPsec-Anbieter offerieren zentralisierte Policy-Managementsysteme, um die Verteilung von Richtlinien zu erleichtern und zu automatisieren. Allerdings geschieht dies nicht immer in einer Weise, die sich sauber mit anderen Netzwerksicherheitsrichtlinien und Policy-Domänen integrieren lässt.

Die Sicherheitsrichtlinie für SSL/TLS-VPNs wird zum größten Teil am Gateway – einem SSL/TLS-Proxy – implementiert und durchgesetzt. Es sind also keine Benutzer oder Geräte involviert, und es gibt kein Remote-Management.

Integration von VPN-Gateways

Serverseitige Fragen gehen in der Begeisterung über Einsparungen durch eine clientlose Implementierung oft unter. Dabei ist das Verständnis dieser Aspekte für die Auswahl von VPN-Produkten, das sichere Systemdesign und die kosteneffiziente Bereitstellung essenziell.

Unabhängig davon, ob Sie sich für IPsec oder SSL/TLS entscheiden, Ihr VPN-Gateway ist die Komponente, auf die es ankommt. Für beides ist eine serverseitige VPN-Administration erforderlich. Bei IPsec sind Netzwerkkonfigurationen das Hauptproblem, bei SSL/TLS ist es die Verwaltung der App-Server.

IPsec-Remote-Hosts werden Teil Ihres privaten Netzwerks. Daher muss die IT folgende Punkte klären:

  • Adresszuweisung: IPsec-Tunnel besitzen zwei Adressen. Die äußeren Adressen stammen von dem Netzwerk, in dem der Tunnel beginnt, zum Beispiel dem Remote-Client. Die inneren Adressen, für das geschützte Netzwerk, werden am Gateway zugewiesen. Die IT muss per Dynamic Host Configuration Protocol (DHCP) oder mit anderen Tools zur IP-Adressverwaltung für das Gateway Adressbereiche bereitstellen. Außerdem muss sie sicherstellen, dass alle internen Firewalls oder sonstigen Sicherheitssysteme diesen Adressen den Zugriff auf die gewünschten Dienste erlauben.
  • Traffic-Klassifizierung: SSL/TLS-Systeme ermöglichen eine granulare Steuerung des Zugriffs auf Services am Gateway. Die Entscheidung, was geschützt werden soll, und das anschließende Festlegen von Selektoren für den Schutz, erfordert Zeit für die Konfiguration und Wartung. Zum Beispiel muss die Anforderung HR-Clients sollen den HR-Server erreichen können auf die richtige Gruppe von Benutzern und Zielsubnetzen, Servern, Ports und URLs abgebildet und im Laufe der Zeit gepflegt werden, wenn sich die Services ändern.
  • Routing: Das Hinzufügen eines IPsec-VPN-Gateways ändert die Netzwerkrouten. Sie werden einige Zeit für die Entscheidung benötigen, wie der Client-Traffic zum und vom VPN-Gateway geroutet werden soll.

SSL/TLS-VPNs erfordern keine Zuweisung von Clientadressen oder Änderungen am Routing innerhalb Ihres Netzwerks, da sie weiter oben im Netzwerk-Stack arbeiten. Typischerweise werden SSL/TLS-VPN-Gateways jedoch hinter einer Perimeter-Firewall eingesetzt, die so konfiguriert werden muss, dass sie SSL/TLS-Traffic an das Gateway weiterleitet. Im Gegensatz dazu entspricht eine Perimeter-Firewall im Allgemeinen dem IPsec-VPN-Gateway.

SSL/TLS-VPN-Gateways können sich positiv auf die Anwendungsserver innerhalb Ihres privaten Netzwerks auswirken. Es kann auch sein, dass der Zugriff granularer eingeschränkt werden muss, als es die Firewall erlaubt, etwa beim benutzerspezifischen Zugriff auf ein Verzeichnis auf einem Webserver.

Dann müssen die IT-Mitarbeiter möglicherweise Zugriffssteuerungen auf Betriebssystemebene anwenden, wie Windows NTFS, und eine Authentifizierung pro Benutzer oder pro Anwendung auf den Servern selbst vornehmen. Dies würde den Zugriff für Mitarbeiter über Firmenendpunkte oder über ein IPsec- beziehungsweise SSL/TLS-VPN kontrollieren.

Durch die Anwendung der gleichen granularen Zugriffssteuerungen an SSL/TLS-VPN-Gateways können Unternehmen diese Sicherheit von den Anwendungsservern auslagern. Außerdem kann eine Organisation einheitliche Richtlinien am Gateway und auf allen internen Systemen erzwingen, selbst wenn das Gateway den Traffic an ein externes Ziel umleitet, beispielsweise einen SaaS-Dienst. Citrix NetScaler etwa ist in der Lage, eine einheitliche Umgebung für Sicherheits-Policies für alle zugelassenen Enterprise-Anwendungen bereitzustellen, ganz gleich, ob lokal oder in der Cloud.

Diese feingranulare Zugriffssteuerung hat ihren Preis: Mehr Planung, Konfiguration und Überprüfung bedeutet einen Mehraufwand. Zudem werden Kontrollen auf den Servern nur dann überflüssig, wenn der gesamte Traffic über die Gateways läuft. Somit stellt die Synchronisierung der Richtlinien eine weitere permanente Aufgabe dar.

Fazit

SSL/TLS-VPN versus IPsec-VPN: Welches VPN-Modell eignet sich am besten? Höchstwahrscheinlich wird IPsec für alle jene attraktiv bleiben, die ein Höchstmaß an Sicherheit, einen umfassenderen Zugriff auf IT-Systeme oder eine Vielzahl von Legacy-Applikationen benötigen. Natürlich spielt auch die Site-to-Site-Konnektivität noch eine Rolle – für die jetzt allerdings immer häufiger kein VPN mehr, sondern Software-defined WAN (SD-WAN) zum Einsatz kommt.

SSL/TLS spielt seine Vorteile bei Umgebungen mit geringerem Sicherheitsniveau aus oder wenn eine zentrale Stelle benötigt wird, um sehr viele feinabgestufte Zugriffsrechte für Benutzer über mehrere Systeme hinweg zu steuern. Es bietet sich darüber hinaus an, wenn sich die Nutzung von IPsec nicht erzwingen oder kontrollieren lässt.

IT-Abteilungen sollten zunächst die spezifischen Anforderungen verschiedener Benutzergruppen bewerten. Dann folgt die Entscheidung, ob ein VPN oder doch ein neueres System das Richtige ist, zum Beispiel ein Tool für Software-defined Perimeter. Außerdem gilt es zu klären, welche Art von VPN die Anforderungen am besten erfüllt und ob die IT es selbst bereitstellen oder einen VPN-Service wie Palo Alto Prisma oder Cisco Umbrella in Anspruch nehmen soll.

Erfahren Sie mehr über LAN-Design und Netzwerkbetrieb

ComputerWeekly.de

Close