SSL-Beschleunigung & SSL-Offload-Lösungen

Die kostengünstigen LoadMaster-Produkte von KEMP beinhalten Layer-4/7-Load-Balancing, Content-Switching und Server-Persistenz, Secure Sockets Layer (SSL) – auch bekannt unter Transport Security Layer (TLS) - SSL-Offload/-Beschleunigung, WTS-Load-Balancing und Persistenz mit Session-Directory-Integration sowie Front-End-Funktionen von Anwendungen (Caching, Komprimierung, Intrusion-Prevention-System) und bieten so ein branchenweit führendes Preis-Leistungs-Verhältnis.

Das Offloading von SSL-Prozessen (Schlüsselaustausch, Aufbau und Trennung von SSL-Verbindungen und Verschlüsselung großer Datenmengen) ist ein sehr rechenintensiver Vorgang und kann einen wesentlichen Teil der verfügbaren Hardware-Ressourcen eines Load Balancers in Anspruch nehmen, die sonst für viele andere Aufgaben zur Verfügung stehen würden (z. B. Load-Balancing, Integritäts-Checks, Content-Switching, Persistenz etc.). Um die Auswirkungen der SSL-Prozesse auf den Load-Balancer zu minimieren, nutzen die meisten führenden SLB-Anbieter spezielle ASIC (Application Specific Integrated Circuits), die nur für die SSL-Beschleunigung optimiert sind.

Im Folgenden finden Sie eine detaillierte Beschreibung der SSL-Beschleunigung

KEMP SSL Everything: SSL-Beschleunigung, die Ihre gesamte Webseite schützt, nicht nur Teile davon

Falls Sie SSL verwenden, besteht die Möglichkeit, dass Sie nicht das gesamte Potenzial ausschöpfen. SSL ist eine leistungsstarke Technologie, die Unternehmen darin unterstützen kann, ihre Daten ebenso wie ihre Benutzer zu schützen. Obwohl SSL auf einer soliden Technologie basiert, sind die bewährtesten und am häufigsten angewandten Implementierungsverfahren nicht in der Lage, die Vorteile von SSL uneingeschränkt zu nutzen. So kann es sein, dass auch in einer modernen Webanwendungsumgebung keine angemessene Sicherheit gewährleistet ist.

SSL-Beschleunigung 101

Zur Erläuterung sollten wir zunächst einmal kurz zusammenfassen, welche Vorteile die SSL-Technologie Unternehmen bietet. Diese Vorteile sind Vertrauen und Datenschutz.

Die Nutzung einer Zertifizierungsstelle (CA), beispielsweise VeriSign oder Thawte, schafft Vertrauen. Mit einem durch eine CA ausgestellten SSL-Zertifikat kann niemand sonst Ihren Domainnamen mit SSL verwenden, ohne dass eine Fehlermeldung irgendeiner Art angezeigt wird.

Verschlüsselung sorgt für Datenschutz, indem Traffic verschlüsselt wird, sodass er für mögliche „Lauscher“ unverständlich wird. Mit regulärem HTTP werden Informationen wie beispielsweise Benutzernamen, Passwörter oder Kreditkartendaten offen über das Internet versandt. Es ist möglich, dass ein solcher Datenverkehr «gesnifft» wird, was vergleichbar mit einem Gespräch ist, das durch jemanden belauscht wird. Dieser Vorgang kann zudem automatisiert werden, sodass er nicht beaufsichtigt werden muss. Ein Programm kann das Netzwerk automatisch sniffen und Informationen herausziehen, die in der Programmerstellung als interessant gekennzeichnet wurden, beispielsweise Passwörter und Kreditkartennummern. Die Verschlüsselung ist daher eines der bedeutendsten Werkzeuge des E-Commerce.

SSL-Beschleunigung in der Praxis

Die Möglichkeit, Vertrauen und Datenschutz zu bieten, versetzt ein Unternehmen in die Lage, sensible Daten zu schützen. SSL wird derzeit hauptsächlich für den Schutz einiger weniger Arten von sensiblen Daten eingesetzt. Diese beinhalten:

  • Passwörter (beim Login)
  • Kreditkartentransaktionen – eine Compliance-Vorgabe der Zahlungskartenindustrie (Payment Card Industry, PCI)

Die meisten Anwendungsbereiche von SSL lassen sich in eine der beiden Kategorien einstufen. Aber gibt es nicht noch mehr sensible Daten, die durch SSL geschützt werden könnten? Man berücksichtige die folgenden Punkte:

  • Memos zu Unternehmensstrategien (Web-Mail)
  • Vertrauliche Vertriebsinformationen (CRM)
  • Geschäftsgeheimnisse (Web-Portal)
  • Sitzungs-IDs (im HTTP-Cookie)

Mit Ausnahme einer gegebenenfalls implementierten VPN-Technologie (Virtual Private Network) wird der Großteil dieser Daten in den meisten Unternehmen in der Regel nicht geschützt. Sie werden regulär über Nicht-SSL-HTTP verarbeitet.

Denken Sie doch einmal einen Moment lang darüber nach, welche Daten Sie über das Internet versenden, die nicht vertraulich sind. Bei welchen Daten wäre es Ihnen also egal, wenn sie in die Hände von Wettbewerbern oder der Öffentlichkeit gelangen würden?

Selbst wenn der Großteil Ihrer Daten nicht vertraulich ist: Können Sie immer mit Sicherheit sagen, auf welche dies zutrifft und welche Daten zwangsläufig doch vertraulich sind? Warum also nicht alle Daten schützen?

Sitzungsschutz

Es gibt noch eine weitere Art von Daten, von denen Ihre Benutzer erwarten, dass sie geschützt werden – auch wenn die meisten sie nicht kennen. Dieser Datentyp nennt sich „Sitzungs-Cookie” Internetprotokolle wurden ursprünglich „zustandslos” entwickelt, das heißt alle Anfragen wurde als voneinander unabhängig behandelt. Als das Internet sich von statischen Webseiten zu interaktiven Webanwendungen entwickelte, musste ein Weg gefunden werden, um eine Beziehung zwischen dem Benutzer und dem Server zu schaffen, damit die Webanwendung die Antworten für den jeweiligen Benutzer anpassen konnte. Dies geschah, indem dem Benutzer eine Sitzungs-ID, meist in Form eines HTTP-Cookies, zugewiesen wurde.

Meldet sich ein Benutzer bei einer Webanwendung an, wird ihm eine Sitzungs-ID zugewiesen. Dabei handelt es sich in der Regel um eine lange, zufällige Folge aus Buchstaben und Ziffern. Der Benutzer schickt diese Sitzungs-ID anschließend bei jeder Anfrage an den Server. Der Server kann daraufhin dynamisch Inhalte für diesen Benutzer erstellen (z. B. benutzerspezifische Portalseiten, private E-Mail-Konten etc.).

Fallen die Sitzungs-ID-Werte in die Hände eines Angreifers, ist dies ein Problem. Denn dieser könnte die Kontrolle über die Sitzung des Benutzers übernehmen, indem er sich für den Benutzer ausgibt, sodass der Server keine erneute Anmeldung verlangt.

Erfolgen nur die Erstanmeldung und möglicherweise auch die Kreditkartentransaktionen über SSL, bedeutet dies, dass der Sitzungs-ID-Wert mehrfach unverschlüsselt über das Netzwerk versandt wird. Dadurch ist es relativ einfach, speziell diese Daten mitzulesen, da kein Datenschutz besteht.

Wo ist also der Haken?

Warum wird SSL angesichts seiner Vorteile und der Art vieler übermittelter Daten nicht standardmäßig verwendet? Um diese Frage beantworten zu können, müssen wir einen Blick auf die Geschichte von SSL und die Entwicklung seiner Nutzung werfen.

Als es ins Leben gerufen wurde, war der größte Nachteil von SSL, dass es mehr Leistung, d. h. Serverressourcen benötigte. Verschlüsselung und Entschlüsselung sind CPU-intensive Vorgänge. Zudem waren CPU für allgemeine Zwecke (z. B. x86 Prozessoren) nicht für diese Aufgabe optimiert. Dies ist auch heute noch der Fall, selbst bei modernen CPU.

Wenn Sie auf einer mit SSL betriebenen Webseite unterwegs sind, bemerken Sie die höhere CPU-Auslastung gar nicht, die für die Entschlüsselung der Webseite benötigt wird. Die wenigen Verbindungen, die Sie geöffnet haben, haben selbst bei einfachen modernen Web-Benutzersystemen keine wesentlichen Auswirkungen.

Aber betrachten Sie das Ganze einmal aus der Serverperspektive: Er gewährleistet Dutzende, Hunderte oder sogar Tausende Verbindungen gleichzeitig. Falls der Server darüber hinaus noch versucht, alles zu verschlüsseln, überlastet das die CPU.

Bei der Bereitstellung von SSL-geschützten Seiten sind Server deutlich stärker gefordert. Stellen Sie sich vor, Sie haben Racks voll mit Servern, um Ihre Webanwendungen bereitzustellen. Anstatt jedoch die CPU für die Bereitstellung Ihrer Anwendungen zu nutzen, setzen diese Server einen wesentlichen Teil ihrer verfügbaren Ressourcen für Verschlüsselung und Entschlüsselung ein. Das ist, als würde man ein Spitzenteam an Hirnchirurgen beschäftigen und ihnen so viel alltäglichen Papierkram aufladen, dass sie nur noch halb so viele Operationen durchführen könnten. Es ist ganz einfach eine Verschwendung wertvoller Ressourcen.

Die traditionelle Denkweise in Bezug auf SSL entspricht also einer Verknappungsmentalität. Da SSL-Ressourcen immer als knapp angesehen werden, verschlüsselt man nur die kritischsten Teile einer Benutzerinteraktion. Nachdem mittels SSL eine Kreditkartennummer übermittelt oder ein Passwort eingegeben wurde, werden Sie auf den nicht SSL-geschützten Teil der Seite zurückgeleitet.

SSL und Anwendungsbereitstellung – 101

Um diese Einschränkungen bei der SSL-Bereitstellung zu beheben, haben Systemdesigner eine neue Technologie entwickelt: SSL ASIC (Application Specific Integrated Circuit). ASIC ähneln typischen Prozessoren, anstatt jedoch zur Durchführung einer ganzen Reihe von Aufgaben zu dienen (Spiele, Textverarbeitung, Surfen im Internet), ist die Funktionalität von ASIC-Prozessoren eng begrenzt. SSL-ASIC sind speziell darauf beschränkt, SSL-Vorgänge durchzuführen – das können sie jedoch ganz hervorragend. Während eine x86-CPU unter Umständen in der Lage ist, 20 neue SSL-Verbindungen in einer Sekunde zu bewältigen, kann ein SSL-ASIC 2.000 neue SSL-Verbindungen verarbeiten.

Ironischerweise war Intel selbst eines der ersten Unternehmen, die einen SSL-Beschleuniger auf den Markt brachten, da selbst Intel erkannt hat, dass x86-CPU bei hohen Datenraten der SSL-Kommunikation ineffizient sind.

Einer der ersten Einsatzorte solcher spezialisierter SSL-Prozessoren war in den Servern selbst. Eine PCI-Karte mit einem SSL-ASIC wurde installiert, damit die Webserversoftware für SSL-Aufgaben auf diese Prozessoren anstatt der allgemeinen CPU zurückgreifen konnten. Der Server war anschließend in der Lage, die Vorteile von SSL-Diensten zu bieten, ohne Leistung einzubüßen. Der Nachteil dieser Methode besteht jedoch darin, dass für jeden Server eine SSL-Karte benötigt wird, was schnell zu hohen Kosten führen kann. Bei 20 Servern und 700 USD pro Karte belaufen sich die Kosten bereits auf 14.000 USD, nur für SSL.

Dann wurden spezielle Netzwerk-Appliances, sogenannte SSL-Beschleuniger, entwickelt und auf den Markt gebracht. SSL-Beschleuniger sind Geräte zwischen Benutzer und Server, die SSL-Verbindungen vom Benutzer akzeptieren und sie unverschlüsselt an den Server senden. Daten, die über das öffentliche Netzwerk versandt werden, sind geschützt und der Server sieht unverschlüsselten Traffic, so dass keine CPU-Ressourcen für SSL benötigt werden.

Dies erwies sich als ein sehr erfolgreiches Modell. So erfolgreich, dass Load-Balancer mit SSL-Beschleunigern kombiniert wurden und sich nun im gleichen Gehäuse befinden. Eine solche Hybridform wird häufig als ADC (Application Delivery Controller) bezeichnet.

Da die SSL-Sitzung auf dem ADC beendet wird, kann der ADC die gleichen Layer-7-Funktionen ausführen, die mit Nicht-SSL-HTTP möglich sind, einschließlich Content-Switching, Cookie-Persistenz und Intrusion-Detection/-Prevention (IPS).

Hier setzt nun die ADC-LoadMaster-Serie von KEMP Technologies an: Einer Servergruppe wird ein KEMP LoadMaster vorgeschaltet, der SSL-Beschleunigung sowie intelligenten Lastenausgleich und Content-Switching anbietet.

Überflussmentalität

Mit dieser neuen Technologie ist es nun möglich, SSL auf Ihre gesamte Webinfrastruktur anzuwenden. Die SSL-Prozessoren verarbeiten SSL-Vorgänge und die Server stehen für die Aufgaben bereit, für die sie bestimmt sind. Dadurch werden Server-Ressourcen für sonstige Aufgaben frei.

Warum wird dies also nicht häufiger getan? Das liegt unter anderem daran, dass SSL lange mit einer hohen CPU-Auslastung gleichgesetzt wurde und sich dieses Denken noch nicht verändert hat. Dafür ist es aber höchste Zeit.

Die Leistungsfähigkeit von Hardware

Der LoadMaster 2500 und der LoadMaster 3500 beinhalten integrierte SSL-Prozessoren. Der Loadmaster 2500 bewältigt 1.000 TPS (Transaktionen pro Sekunde), beim Loadmaster 3500 sind es 3.000 TPS.

Aber reicht das auch? Ist das genug SSL-Leistung, um nicht nur die Passwort- und Kreditkarten-SSL, sondern die gesamte Webseite auf den LoadMaster zu verschieben? Und wie lassen sich SSL-TPS in vertrautere Webkennzahlen übersetzen? Um diese Fragen zu beantworten, werfen wir einen Blick auf die recht gut verständlichen Parameter Seitengröße und Bandbreite.

Klären wir zunächst einmal, was TPS bedeutet. Das „T” in TPS steht für die SSL-Erstverbindung. Dabei handelt es sich mit Abstand um den CPU-intensivsten Teil des gesamten Prozesses. Die Erstverbindung erfordert den meisten Aufwand, hier ist ein SSL-Beschleuniger von großem Vorteil.

Mit einer vorgegebenen Webseitengröße und ein bisschen Mathematik erhalten Sie einen Eindruck von der Bandbreite, die eine bestimmte TPS-Anzahl ermöglichen kann. Nehmen wir beispielsweise eine Webseite mit einer Größe von 100 Kilobyte (einschließlich HTML und Bildern, dies entspricht einer durchschnittlichen Seitengröße). Wie viel Bandbreite können 1.000 TPS bei einer Seitengröße von 100 Kilobyte erzeugen? Gehen wir einmal von HTTP 1.1 aus, sodass alle 100 KB voller Objekte in einer einzigen Sitzungsverbindung (und damit in einer einzigen SSL-Transaktion) abgefragt werden. 100 Kilobyte entspricht 800 Kilobit bzw. 800.000 Bit. Multipliziert mit 1.000 bedeutet dies, dass 800.000.000 Bit in einer einzigen Sekunde möglich sind. Dies entspricht 800 Megabit, eine enorme Menge an Traffic und mehr als man für den LM-2500 braucht. Die im LM-3500 verfügbaren 3.000 TPS entsprechen jedoch mehr als 1 Gigabit, auch das ist mehr, als Sie benötigen. Natürlich wirken sich unterschiedliche Seitengrößen und das Surfverhalten von Benutzern auf diese Zahlen aus. Sie sind dennoch ein guter Indikator für die Leistung, die Sie erwarten können. Unter dem Strich bedeutet dies: Die Anzahl der im LM-2500 und LM-3500 verfügbaren TPS beträgt mehr als Sie voraussichtlich benötigen. Die TPS bringen also keine Einschränkungen mit sich. Die SSL-Leistung ist für praktisch alle kleinen und mittleren Unternehmen (KMU) ausreichend. Mit den zusätzlichen SSL-Lizenzen entstehen Ihnen zudem keine weiteren Kosten für den SSL-Schutz Ihrer gesamten Webseite, wie es der Fall wäre, wenn Sie einzelne SSL-Karten für jeden Server kaufen müssten.

Eine einfache Wahl

Warum sollte man mit hardwarebasierten SSL-Prozessoren, die SSL-Vorgänge für ganze Webinfrastrukturen ohne Einbußen bei Leistung und Kapazität auslagern können und durch die keine zusätzlichen Kosten (im Vergleich zu keinem SSL) entstehen, nicht gleich alles mit SSL schützen? Sie hätten alle Vorteile und keine Nachteile.

Mit der Leistungsfähigkeit der in die Anwendungsbereitstellungs-Controller integrierten SSL-Prozessoren und ohne zusätzliche Kosten gibt es keinen Grund mehr, Ihre gesamte Webseite nicht mit SSL zu schützen. Die Kosten liegen bei Null, mögliche Risiken werden begrenzt und Ihre Benutzer werden, wenn überhaupt, nur positive Veränderungen bemerken.

Über KEMP Technologies

KEMP Technologies ist ein führender Anbieter im Bereich kosteneffektiver Anwendungsbereitstellungs-Controller und Server-Load-Balancer-Appliances, die auf die Bedürfnisse kleiner und mittlerer Unternehmen (KMU) zugeschnitten sind, die sich für E-Commerce und geschäftskritische Anwendungen auf das Internet verlassen. KEMP unterstützt KMU dabei, ihre Geschäftstätigkeit durch Rund-um-die-Uhr-Verfügbarkeit, eine leistungsfähigere Webinfrastruktur, Skalierbarkeit und sicheren Betrieb zu steigern – und dabei die IT-Kosten unter Kontrolle zu halten.

Tausende von KEMP LoadMaster-Produkten sorgen aktuell für mehr Kundenzufriedenheit durch schnelleren Zugriff der Benutzer auf geschäftskritische Webanwendungen. Auch Managed-Service-Anbieter vertrauen den Produkten von KEMP und ermöglichen so ein kurze Markteinführungszeiten und einen kosteneffizienten Betrieb für neue und bereits vorhandene Managed-Services.

Die kostengünstigen LoadMaster-Produkte beinhalten Layer-4/7-Load-Balancing, Content-Switching und Server-Persistenz, SSL-Offload/-Beschleunigung, WTS-Load-Balancing und Persistenz mit Session-Directory-Integration sowie Front-End-Funktionen von Anwendungen (Caching, Komprimierung, Intrusion-Prevention-System) und bieten so ein branchenweit führendes Preis-Leistungs-Verhältnis.