IPsec versus SSL: Machtwechsel. Im Remote-Access-Szenario »Mobiler Anwender ? Zentrale« läuft das IPsec-Protokoll Gefahr, seine dominante Stellung an das SSL-Verfahren zu verlieren. Der Emporkömmling ist flexibler und verspricht weitaus geringere Betriebskosten.

IPsec versus SSL: Machtwechsel

Autor: Michael Piontek
Selten haben Analystenaussagen den Niedergang einer Technik so deutlich angekündigt wie Gartner in der Studie zum Thema »SSL versus IPsec«: Das Marktforschungsunternehmen schätzt, dass im Jahr 2006 rund 80 Prozent der Remote-Szenarien weltweit das SSL-Verfahren nutzen werden. Ein Bereich, den aktuell das IPsec-Verfahren unangefochten dominiert. Amerikanische Start-ups wie Netilla und Neoteris, letzterer vergangenes Jahr von Netscreen gekauft, haben die Studie gerne aufgegriffen, um ihren eigenen SSL-Konzepten gegenüber der Konkurrenz Gewicht zu verleihen. Sicherheitsanbieter wie Stonesoft, die weiter auf IPsec schwören, konterten: SSL sei viel zu unsicher, um den Remote Access im Geschäftsbereich abzusichern. Ein fragwürdiges Argument, weil nahezu alle Online-Banking Accounts ihren Datenaustausch per SSL kodieren. Warum aber soll SSL eine solche Erfolgsgeschichte erleben?

Die Technik setzt an einer Stelle an, die auf IPsec basierenden Konzepten schon immer Probleme bereitet: Am Client. SSL verzichtet gänzlich auf einen solchen. Der mobile Anwender loggt sich über seinen klassischen Browser ein und erhält so Zugriff auf alle für ihn relevanten Informationen. Seine Daten werden mit 128-Bit-RC4-Schlüsseln verfremdet und sind für Dritte unleserlich.

Um sich dagegen über IPsec einzuwählen, muss eine dezidierte Client-Software auf den Client-Rechnern installiert sein. Fast alle Hersteller geben diese Software kostenlos ab. Nur wenige, beispielsweise Check Point, haben eine gesonderte, kostenpflichtige Version entwickelt. Wer mit einem Produkt keinen Umsatz macht, fokussiert die Entwicklung jedoch auch auf andere Bereiche. Statt also das Remote Management ihrer Clients zu verbessern, haben die IPsec-Hersteller leistungsstärkere Appliances entwickelt. Und dabei übersehen, dass die mangelhaften Remote-Management-Funktionen in der Praxis den Support-Aufwand und die Betriebskosten erhöhen. Dass die Software dafür nichts kostet, ist in der Gesamtbetrachtung dann zu vernachlässigen.

Problemfelder

Die SSL-Hersteller versprechen, dass ihr Konzept alle Remote-Access-Einsatzszenarien abbilden könnten. So problemlos und universell ist ihr Ansatz aber nicht. Das liegt am Prinzip von SSL. Das Verfahren setzt im Gegensatz zu IPsec nicht auf der Netzwerk-, sondern auf der Applikationsebene auf. SSL kodiert nur den Datenteil (Payload) im IP-Paket und spricht direkt mit der Applikation. Diese muss das SSL-Verfahren im Prinzip auch unterstützen und daher auch auf IP basieren. Aber nicht alle Anwendungen erfüllen diese Bedingung.

Um das Problem zu lösen, arbeiten die SSL-Appliances als Proxy. Der mobile Anwender steuert die Appliance per URL-Adresse an. Dort werden seine Anfragen in interne Protokolle übersetzt und an die jeweiligen Applikationen durchgereicht. Für jede Session muss eine Appliance daher zwei Verbindungen etablieren. Bei der Protokoll-Übersetzung wird also das HTTP/S des Anwenders beispielsweise in FTP oder NFS umgewandelt, so dass der Anwender mit einem File Server sprechen kann. Genauso gelingt die Kommunikation zwischen Browser und den E-Mail-Protokollen SMTP, POP3 oder IMAP. Diese Funktionen sind in der Regel standardmäßig in den Appliances integriert.

Schwierig wird es bei Legacy-Applikationen, die HTTP-fremde Protokolle verwenden oder gar kein IP verstehen. Hier wird sich die Qualität der Produkte zeigen. Je komplexer diese Anwendung, desto wahrscheinlicher ist es, dass die Anbieter gegen ihr Client-loses Versprechen verstoßen. Sie müssen in diesem Fall einige Funktionen auf dem Client abbilden und greifen zu diesem Zweck auf Actice-X-, Java-Applets oder Java-Skript zurück. Will der mobile Anwender eine dieser Applikationen nutzen, muss er das dazugehörige Programm herunterladen. Ob dabei unterschiedliche Browser-Versionen technische Probleme verursachen, muss die Praxis zeigen. Sicher ist, dass einige Unternehmen auf Grund ihrer Sicherheitspolitik diesen aktiven Code nicht zulassen. Ihre komplexe Applikation würde aus dem SSL-Konzept herausfallen.

Inzwischen verstehen auch PDAs, Mobiltelefone und andere rechnerfremde Systeme SSL über ihre Micro-Browser. Gerade Nokia hofft dadurch auf einen Siegeszug von SSL. So verlockend diese Aussicht auch ist, sie verursacht ein grundlegendes Problem: Jedes Gerät etabliert ein unterschiedliches Sicherheitsniveau. Deswegen waren die SSL-Anbieter gezwungen, Funktionen zu entwickeln, um die Client-Integrität zu prüfen, bevor sie die Verbindung erlauben. Wer nämlich einen legalen Benutzer-Account nebst gültigem Passwort besitzt, könnte sich auch aus einem Internet-Café heraus einwählen. Ob diese Rechner die internen Sicherheitsbestimmungen des Unternehmens erfüllen, ist mehr als fraglich.

Die Integritätsfunktionen haben zwei Aufgaben: Sie sollen prüfen, ob beispielsweise ein Virenscanner auf dem Client läuft. Und sie sollen das Gerät identifizieren, mit dem sich der Anwender einwählt. Diese Informationen dienen dazu, geräteabhängig Zugriffsrechte einzuschränken oder zu erweitern. Wählt sich der Anwender per PDA ein, darf er nur E-Mails lesen, während ihm sein Notebook, das per Virenscanner und PC-Firewall geschützt ist, auch den Zugriff auf kritische Geschäftsapplikation gewährt.

Array Networks und Netilla gehen sogar soweit, einen kleinen Virenscanner als Applet vorneweg herauszuschicken und erst nach gelungener Prüfung einen verschlüsselten Container auf den Clients aufzusetzen. Dort laufen alle Daten und Applikationen isoliert vom Restsystem ein. Ist die Session beendet, wird der gesamte Container nebst Inhalt automatisch gelöscht. Damit trennen sie sich von ihrem Client-losen Konzept und riskieren, dass die Active-X-Java-Thematik den Supportaufwand erhöht.

___________________________________________

Kompakt

Damit SSL-Appliances ihre IPsec-Pendants im Mobile-User-Zentrale-Szenario ersetzen können, müssen sie deren grundlegende Sicherheitsdisziplinen beherrschen. Dazu gehören zentrales Management genauso wie filigrane Logging- und Reporting-Funktionen. Auch bei der Authentifizierung sollte das SSL-System eine ebenso breite Palette einbinden, wie es die IPsec-Lobby bereits tut. Neben statischen Passwörtern zählen dazu Token, Smartcards und digitale Zertifikate wie auch Onetime-Passwörter. Hochverfügbarkeit, Cluster-Funktionen und Durchsatzstärke spielen ebenfalls eine Rolle. Denn niemand wird bereit sein, für einen geringeren Support-Aufwand an anderer Stelle an Sicherheit oder Leistung einzubüßen.