LoadBalancerBlog.de

SSL-Beschleunigung ist einer der größten Extra-Pluspunkte eines geeigneten Load Balancers – für manche Anwender sogar der Hauptzweck. Doch funktioniert das auch in jedem Fall? Ja – wenn man einige Grundvoraussetzung schafft. Hier steht, welche das sind.Sehen wir uns zunächst nochmal an, was SSL Beschleunigung bedeutet:

• Der Load Balancer nimmt eine HTTPS-Anfrage der Browser entgegen (auf dem Standardport 443, oder einem individuellen)
• Der Load Balancer führt dann den SSL (korrekt müsste man eigentlich sagen: TLS) Sessionaufbau durch.
  Anmerkung: Dies ist übrigens der performance-intensive Teil einer SSL-Verbindung, daher ist die relevante Messgröße ebendiese Anzahl, vereinfacht gesagt: Die neuen Verbindungen pro Sekunde (“Transaktionen” pro Sekunde, TPS).
• Ab hier entschlüsselt der Load Balancer alle ankommenden Daten und gibt sie als normales HTTP zu seinen Real Servern weiter.
  Anmerkung: Auf den Sonderfall, dass nach Vorverarbeitung durch den Load Balancer wieder eine Verschlüsselung erfolgt und die Real Server per HTTPS angesprochen werden, soll in diesem Zusammenhang nicht eingegangen werden.
• Auf dem Rückweg werden die (HTTP-) Antworten der Real Server natürlich auch wieder verschlüsselt, bevor sie zum Browser geschickt werden.

Die Vorteile liegen auf der Hand:

• Erhebliche CPU-Entlastung der Real Server,
• Zentrales Management der SSL-Zertifikate.

Aber… nicht immer geht dies ohne Änderungen. Das Kernproblem: Alle Links, Redirects etc. zur Anwendung müssen am Browser als HTTPS  vorliegen, während die Anwendung ja auf HTTP angesprochen wird und daher “auf die Idee kommen könnte”, URLs zu sich selbst mit “http://” beginnen zu lassen.

Was kann man in solchen Fällen tun? Hier sind die möglichen Lösungswege:

1. Absolute URLs vermeiden
   Solange alle URLs relativ sind (z.B. auf /checkout.php zeigen statt auf http://<meinshop>.com/checkout.php)
   und wenn im HTML kein “base href” (http://de.selfhtml.org/html/kopfdaten/basis.htm)
   angegeben ist, kann das Problem gar nicht erst entstehen.
2. Anwendung auf https:// festlegen
   Wird “base href” (s.o.) verwendet, so kann dieser fest auf die entsprechende “https://” Adresse gesetzt werden. Werden absolute Links oder HTTP Redirects verwendet, so können diese fest auf die entsprechende “https://” Adresse zeigen. In beiden Fällen muss dies in der Anwendung eingestellt werden (können). Nachteil in beiden Fällen: Andere Zugriffswege ohne HTTPS, und sei es nur zu Testzwecken, sind dann nicht mehr möglich.
3. Anwendung intelligent (fallweise) auf https:// zeigen lassen
   Intelligenter als vorgenannter Weg ist folgender: Die Anwendung erkennt, dass eine Anfrage ursprünglich über HTTPS hereinkam (aber bereits vom Loadbalancer entschlüsselt wurde), und generiert in diesem Falle ihre Links mit “https://”.
   Die Gretchenfrage lautet nun: Wie kann die Anwendung dies erkennen?Weg 1: HTTP Header Injection
   Der KEMP LoadMaster kann verschiedene HTTP Header setzen, die von der Anwendung ausgewertet werden können. Die eingefügten Header-Zeilen könnten z.B. so aussehen:

   X-ClientSide: 192.168.30.10:1842 -> 192.168.20.150:443
   Via: HTTPS/1.1 192.168.20.150:443

   — veraltet! Siehe Update unten —
   Erfordert die Anwendung einen bestimmten Header (“WL-Proxy-SSL: true”, “Front-End-Https: on”, …), so kann dieser sehr einfach etwa durch den annehmenden Apache eingefügt werden. Beispiel (httpd.conf):
   

   SetEnvIf Via HTTPS* SSLpresent
   RequestHeader add WL-Proxy-SSL "true" env=SSLpresent

   — veraltet! Siehe Update unten —

4. Weg 2: Verschiedene Virtuelle Hosts
   Kann die Anwendung ihr Verhalten für den Fall modifizieren, dass sie anders angesprochen wurde (z.B. auf einem anderen TCP-Port oder einer anderen IP-Adresse, jeweils natürlich auf dem gleichen Server), dann kann z.B. für HTTP-Verbindungen, die ursprünglich HTTPS waren, auf dem Real Server zusätzlich Port 81 freigegeben werden, der nur vom SSL-Beschleuniger angesprochen wird.
5. Redirects auf dem Load Balancer
   Wenngleich der KEMP LoadMaster mit der Option “Add a Port 80 Redirector VS” eine sehr einfache Möglichkeit bietet, alle fälschlicherweise auf Port 80 ankommenden Anfragen auf HTTPS umzuleiten (per HTTP Redirect), ist dies keine empfohlene Lösung.
   Die Gründe: GET-Requests laufen unverschlüsselt, POST-Requests können gar nicht umgeleitet werden, und überhaupt wird unnötiger Zusatztraffic und Verlangsamung erzeugt.
   Sollte es jedoch einzelne URLs geben, in denen die Anwendung nicht sauber reagiert (und für welche die vorgenannten Einschränkungen irrelevant sind), so kann die Situation damit gerettet werden.

[Update] Anwendungsspezifische HTTP-Header

Ergänzend noch etwas genauere und detaillierte Angaben zu  3-1, was ja meine empfohlene Methode ist. Zum einen einige konkrete Beispiele für Standard-Header zum SSL Oflloading:

Oracle / Bea: “WL-Proxy-SSL: true”
Microsoft (verschiedene Produkte): “Front-End-Https: on”
IBM Websphere: “HttpsIndicatorHeader: <beliebiger Wert>”

Außerdem hier die in 2010 hinzugekommene Möglichkeit, beliebige HTTP Header direkt im LoadMaster zu setzen:

(Der o.g.  Apache-Rewrite entfällt also inzwischen komplett.)