Passphrase zum Start

Abschließend muss man Apache einmal neu starten, unter Debian etwa mit »/etc/init.d/apache2 restart« . Apache fordert dabei die Passphrase für den privaten Schlüssel ein. Verhindern kann man das nur, indem man die Verschlüsselung wieder entfernt. Damit ist der private Schlüssel aber ungeschützt, was wiederum ein Sicherheitsrisiko darstellt. Kommen mehrere per SSL gesicherte virtuelle Hosts zum Einsatz, versucht Apache die eingetippte Passphrase auch auf alle übrigen privaten Schlüssel anzuwenden. Im Idealfall muss man so nur einmal eine Passphrase eintippen.

Sobald der User jetzt die verschlüsselte Seite ansteuert – in den bisherigen Beispielen »https://login.example.com« – warnt der Browser bei einem selbst erstellten Zertifikat vor mangelnder Sicherheit ( Abbildung 3 ). Hier bleibt dem Anwender nur, das Zertifikat per Hand als vertrauenswürdig einzustufen. Anschließend läuft die Kommunikation verschlüsselt ab.

Abbildung 3: Selbst erstellte Zertifikate weisen die Browser mit einer entsprechenden Meldung zunächst zurück.

Qual der Wahl

Neben den drei SSL-Direktiven aus Listing 1 kennt Apache noch ein paar weitere. Besonders interessant ist »SSLCipherSuite« . Sie gibt an, welche Verschlüsselungsalgorithmen der Webserver für den SSL-Handshake akzeptiert. Der Direktive folgt dabei eine durch Doppelpunkte getrennte Liste mit den möglichen Algorithmen. Angeben muss man dabei jeweils mindestens einen Algorithmus für den Schlüsselaustausch, die Authentifizierung, die Verschlüsselung und die Integritätsprüfung. Ein Beispiel für eine solche Auswahl wäre:

SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP

Diese Liste sieht auf den ersten Blick ziemlich wüst aus, erklärt sich aber schnell: Jeder Algorithmus erhält ein Kürzel, »RC4« steht beispielsweise für den RC4-Algorithmus. Alle weiteren Kürzel stellt Tabelle 1 vor. Damit man sich nicht die Finger wund tippt, gibt es netterweise noch Abkürzungen beziehungsweise Alias-Namen. So steht »SSLv2« für alle vom SSL-2-Standard unterstützten Algorithmen, »ALL« für alle möglichen. Die übrigen Abkürzungen listet Tabelle 2 auf. »Exportfähig« bezieht sich dabei auf die Ausfuhrbeschränkungen der USA, nach denen besonders starke Verschlüsselungsverfahren nicht exportiert werden dürfen. »EXP« enthält somit nur Verfahren mit geringer Schlüssellänge.

Schließlich darf man bestimmte Algorithmen noch bevorzugen oder ausschließen. Das zeigen die Sonderzeichen »+« , »-« und »!« an, die den Kürzeln vorangestellt werden. »!« verbietet einen Algorithmus, »!ADH« schließt im obigen Beispiel folglich alle Algorithmen aus, die Anonymous Diffie-Hellmann verwenden. Das Minuszeichen »-« entfernt ebenfalls einen Algorithmus, der sich aber später in der Kette wieder hinzufügen lässt. Mit dem Pluszeichen kann man einen Algorithmus explizit an die entsprechende Position der Liste setzen und so die Reihenfolge beeinflussen. Im obigen Beispiel würde der Webserver etwa die Algorithmen aus der »HIGH« -Gruppe denen der »MEDIUM« -Gruppe bevorzugen. Abschließend kann man auch noch mehrere vorgegebene Cipher-Suiten auswählen, indem man zwischen den Kürzeln ein »+« einfügt. Im obigen Beispiel wären mit »RC4+RSA« alle Cipher-Suiten möglich, die »RC4« und »RSA« enthalten. Das Beispiel ist übrigens gleichzeitig der Standardwert unter Apache 2.2. Apache 2.4 übernimmt hingegen die Standardeinstellungen von OpenSSL.

Welche Algorithmenkombinationen mit einer Einstellung möglich sind, verrät der Befehl »openssl ciphers -v« . Ihm hängt man einfach den zu untersuchenden Bandwurm an:

openssl ciphers -v 'ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP'

Das Ergebnis ist eine Tabelle wie die aus Abbildung 5 . Die erste Spalte listet die Namen der Cipher-Suiten auf, die zweite nennt den SSL-Standard. Es folgen in den weiteren Spalten die Algorithmen für den Schlüsselaustausch, die Authentifizierung, die Verschlüsselung und die Integritätsprüfung.

Abbildung 5: Die möglichen Algorithmenkombinationen zeigt openssl an.

Die großen Browser bevorzugen normalerweise sichere Algorithmen, derzeit vor allem AES, die jedoch mehr Rechenzeit kosten. Administratoren, die stattdessen auf schnellere, einfachere Verfahren setzen, leben gefährlich: So geriet zuletzt RC4 in die Schlagzeilen. Mehr zu Problemen mit TLS verrät ein Artikel in der Security-Rubrik dieses Hefts.

Man sollte daher nicht mit einer eigenen »SSLCipherSuite« -Regel die vom Client vorgeschlagenen, sicheren Verfahren überstimmen. Beschleunigen kann man die Codierung, indem man OpenSSL eine eventuell vorhandene Kryptohardware nutzen lässt. Das setzt allerdings voraus, dass OpenSSL mit »Engine« -Unterstützung übersetzt wurde ( Abbildung 6 ). Ab OpenSSL 0.9.7 ist dies standardmäßig der Fall. Welche Hardwarebeschleuniger dann zur Verfügung stehen, verrät:

openssl engine

Von diesen wählt man einen aus und setzt den Namen in die Klammern hinter die Direktive »SSLCryptoDevice« , wie etwa:

SSLCryptoDevice rsax

Zusätzlich lässt sich auch ein Cache für Session-Daten einrichten:

SSLSessionCache dbm:/tmp/cachedatei

In diesem Fall würde Apache die DBM-Datei »/tmp/cachedatei« verwenden.

Abbildung 6: Auf diesem Core i7 unter Open Suse 12.3 gibt es nur ein Crypto-Device für hardwarebeschleunigte Verschlüsselung.