Seit einiger Zeit (mehrere Monate bereits) setze ich wegen SNI (Server Name Indication) auf mod_gnutls statt mod_ssl, damit ich mehrere SSL VHosts auf einer IP nutzen kann.
Jetzt hat sich gestern aber mod_gnutls an seinem Cache unter /var/cache/apache2/gnutls_cache verschluckt, was einige unangenehme Folgen hatte.
- Massives Loggen von “PANIC: fatal region error detected; run recovery” in /var/log/apache2/error.log (~25MB/s)
- Extrem hohe Last auf dem Server
- Vollaufen der Festplatte (bzw. der Log-Partition)
- nahezu keine Reaktion auf http/https vom Apache2 auf Anfragen an diesen
- Diverse Kernel Stack Traces, zumeist als Konsequenz der vollen Festplatte
Was als Sofort-Maßnahme hilft, ist das Töten des Apache2 (killall -9 apache2), löschen von /var/cache/apache2/gnutls_cache und /var/log/apache2/error.log und den Webserver wieder starten.
Interessant ist natürlich, warum sein Cache korrumpiert wurde und eigentlich noch viel interessanter, warum mod_gnutls es überhaupt für nötig befindet, einen Cache anzulegen (mod_ssl kommt auch ohne aus). Die Einstellung findet sich übrigens hier: /etc/apache2/mods-available/gnutls.conf. Dort wird im Übrigen auch erwähnt, dass die DBM Variante auch nicht die Schnellste ist. Daher wollte ich einfach mal ein paar MB für einen memcached Dienst abzacken und diesen als Backend-DB für den gnutls-Cache nutzen. Dummerweise bin ich da mal wieder zum x-ten mal in einen Debian-Bug reingerannt (ja es häuft sich ganz extrem), denn der memcached Support ist gar nicht mit einkompiliert (anders als die Doku und das Config File vermuten lassen.)
Ebenfalls undokumentiert ist die Möglichkeit, den dummen, obsoleten Cache ganz abzustellen. Dazu einfach Folgendes in die Config /etc/apache2/mods-available/gnutls.conf einfügen:
GnuTLSCache none none
Läuft auch nicht langsamer als die DBM-Variante und sollte weit weniger fehleranfällig sein.
Die entsprechende Cache-Datei kann dir auch mod_ssl schreiben. Konfiguration dazu ist SSLSessionCache. Dieses Caching ist auch auf jedem Host sinnvoll, der mehr als nur eine Hand voll Anfragen pro Tag über HTTPS beantwortet. Es geht dabei gar nicht so sehr um die Auslieferungsgeschwindigkeit der Seiten. Mit dem Caching wird vor allem erreicht, dass auf einen bereits ausgetauschten Sessionkey zurückgegriffen werden kann. Mit diesem Sessionkey kann einfach gesagt dann direkt mit AES oder dergleichen gearbeitet werden. Das spart dem Server einige Public-Key-Berechnungen (RSA, DSA, DH) und bewirkt damit eine bessere Skalierbarkeit und weniger Rechenlast auf der CPU. Der eigentliche Rechenaufwand der Verschlüsselung über SSL/TLS steckt nämlich in dieser Public-Key-Kryptografie. Die daran anschließende AES-Verschlüsselung fällt nicht sonderlich ins Gewicht.
Damit kannst du also letztendlich mehr Besucher verkraften ohne die Hardware aufrüsten zu müssen.
Nebenbei: Du musst auch mit mod_ssl niemanden mehr aussperren, der kein SNI kann. Keyword dazu ist “SSLStrictSNIVHostCheck”. Default ist sogar “off”.
Ist richtig, SNI via mod_ssl schließt aber dann meines Wissens den IE6 auf XP ganz aus, anstatt ggf. nur ne Zertifikatswarnung dort zu provozieren.
Das könnte mir fast egal sein der IE6 Anteil geht bei mir nahezu gegen null, aber gibt einige Leute, die auch soche Kunden ausquetschen wollen.
Guggstu, mod_ssl kann das mittlerweile auch:
http://sni.velox.ch/ct_2309_Apache_TLS_SNI.pdf
Hier gefunden: http://www.howtoforge.com/hosting-multiple-ssl-web-sites-on-one-ip-address-with-apache-2.2-and-gnutls-debian-lenny
You can test if your browser is passing SNI by visiting here: https://sni.velox.ch/