Langsam aber sicher setzt sich die verschlüsselte Kommunikation per TLS auch auf Internetseiten (HTTPS) durch. Gut konfiguriert verhindert sie effektiv das Mitlesen der gesendeten Informationen und Einschleusen fremder Codestücke. Wichtig hierbei ist, dass der zugehörige Webserver richtig konfiguriert ist. Ich werde hier auf den aktuellsten Ableger des Apache HTTPd, die Version 2.4, eingehen. Alle Einstellungen werden im jeweiligen virtual Host vorgenommen und sollten teilweise bereits vorhanden sein. Bei Arch Linux befindet sich die SSL-Konfiguration unter /etc/httpd/conf/extra/httpd-ssl.conf.

Zertifikatstheorie

TLS, und damit auch HTTPS, arbeiten mit einem hierarchisch organisierten System. Viele Browser und Betriebssysteme liefern eine Liste mit vertrauenswürdigen Organisationen mit – ist das eigene Zertifikat nicht, zumindest indirekt, von einer dieser Organisationen unterschrieben, so wird eine Sicherheitswarnung angezeigt. Ob dies Sinnvoll ist kann kritisch beäugt werden, vor allem wenn man bedenkt, dass z.B. auch diverse Banken, Regierungen oder Organisationen, welche in der Vergangenheit eher durch Sicherheitsmängel aufgefallen sind, auf dieser Liste stehen. Generell erstell man selbst einen Key, den privaten Schlüssel des Zertifikates, und leitet hiervon einen Request (CSR) ab. Letzterer – und nur dieser – wird an die Zertifizierungsstelle (CA) zum Unterschreiben gegeben. Nachdem die eigene Identität nachgewiesen wurde wird aus Request und Unterschrift das eigentliche, öffentliche Zertifikat, welches das eigene, zweiteilige Schlüsselpaar komplettiert. Als Betreiber hat man hier mehrere Möglichkeiten ein solches SSL-Zertifikat zu erhalten:

• Kaufen. Die diversen Organisationen bieten ihre Unterschriften üblicherweise gegen Gebühr an. Für eine eizelne Domain ohne Zusatzfunktionen sind etwa 15€/Jahr fällig, möchte man Subdomains oder erweiterte Sicherheitsfunktionen kann der Preis schnell auf über 1000€/Jahr steigen.
• Selber machen. „Selbstsignierte“ Zertifikate sind prinzipiell auch möglich, hier wird aber eine Sicherheitswarnung angezeigt. Der Nutzer muss selbst bestätigen, dass er dem Zertifikat vertraut. Für interne Systeme, auf denen man zentral ein Zertifikatsvertrauen ausrollen kann kein Problem, ansonsten eher nur für eigene Testsysteme geeignet.
• StartSSL. StartCom stellt mit StartSSL kostenfrei SSL-Zertifikate zur Verfügung. Die Israelische Firma wird von allen gängigen Browsern als Vertrauenswürdig eingestuft. Bedenklich ist jedoch, dass das zurückziehen im Falle eines Sicherheitsproblem Gebühren verursacht und so dazu verleitet bei Problemen die Augen zuzukneifen.
• CACert …ist eine freie, communitybasierte Zertifizierungsstelle. Auch hier lassen sich kostenfrei Zertifikate signieren, die Qualität der Signatur steigt mit der Anzahl der Personen, welche die Identität prüfen. Leider ist CACert auf vielen Systemen nicht hinterlegt, somit werden auch hier ohne manuellen Eingriff Sicherheitswarungen angezeigt.
• Let’s Encrypt geht einen ähnlichen, allerdings weniger Community-Zentrierten weg. Sie möchte automatisiert und kostenfrei einfache SSL-Zertifikate bereitstellen. Dahinter stehen Internetgrößen wie Mozilla, Akamai, Cisco oder die EFF, es ist also davon auszugehen, dass die Vertrauensstellungen machbar sein sollen. Warum soll? Let’s Encrypt wird erst mitte Oktober 2015 starten.

Wir basteln einen Request

Welchen weg auch immer man geht: Wir brauchen einen Key und den passenden Request. Fangen wir mit ersterem an:

cd /etc/ssl/private
openssl genrsa -out server.key 4096

Der Schlüssel nutzt den RSA-Algorithmus mit einer Länge von 4096 Bit. Empfohlen wird >=2048 Bit, wer aber nicht unbedingt auf die letzten CPU-Takte Performance schaut sollte diese zugunsten der vermutlich längeren Zukunftssicherheit investieren.

Auf Basis dieses Schlüssels wird nun der Request erstellt:

openssl req -new -key server.key -out server.csr -sha512

Die Attribute wie Adresse sollten passend den eigenen Angaben ausgefüllt werden. Wichtigster Punkt: Der „Common Name“ (CN) muss dem Servernamen entsprechen.

Diesen Request übersendet man nun der Zertifizierungsstelle, die Antwort wird als „server.crt“ im selben Verzeichnis gespeichert. Sollte man ein so genanntes „intermediate“ benötigen (Das eigene Zertifikat wurde von jemandem unterschrieben welcher selbst nicht vertrauenswürdig ist aber eine Unterschrift einer anderen, vertrauenswürdigen Stelle hat), so werden diese Zertifikate einfach am Ende der Textdatei drangehangen.

Apache-Konfiguration

Erster Schritt: Wir schalten „SSL“ (so hies TLS früher mal, Apache hat die Namen beibehalten) ein und geben den Pfad zum Zertifikat an.

SSLEngine on
    SSLCertificateFile      /etc/ssl/private/server.crt
    SSLCertificateKeyFile   /etc/ssl/private/server.crt

Als Nächstes werden die möglichen Protokollversionen und Algorithmen festgelegt. Bei ersterem sollte alles mit SSL abgeschaltet werden – diese haben bekannte Sicherheitslücken. Auch zu TLSv1 gibt es einige Bedenken, jedoch noch keinen praxisrelevanten Angriff – wer auf Nummer sicher gehen will kann auch dies Abschalten, jedoch sperrt man hiermit möglicherweise ältere Geräte und Browser aus. Bei den Ciphern ist die Reigenfolge entscheidend – der erste Eintrag, welcher von Server und Client unterstützt wird, wird verwendet. Einträge mit *DHE* bieten „perfect forward secrecy“ (PFS) – hierbei wird für jede Verbindung ein temporäres Passwort abgewandelt. Liest ein Bösewicht die verschlüsselten Daten mit kann er sie später, auch wenn er den Server knackt und so an die Schlüssel kommt, nicht mehr entschlüsseln. RC4 und MD5 werden wegen ihrer hohen Geschwindigkeit zwar gerne von Großkonzernen und einigen Banken verwendet, haben aber bekannte Lücken, sodass sogar das Bundesamt für Sicherheit in der Informationstechnik (BSI) vor deren Einsatz warnt. Die SSL-Kompression hat ebenfalls eine gewisse Angriffsfläche und sollte abgeschaltet werden. Wie immer gilt: Je mehr man auf Sicherheit Wert legt, desto mehr alte Geräte sperrt man aus.

    SSLProtocol             all -SSLv3 -TLSv1
    SSLCipherSuite          ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK
    SSLHonorCipherOrder     on
    SSLCompression          off

Bei neueren Servern kann man die Ladezeit des Besuchers noch etwas drücken: Dessen Browser geht üblicherweise hin und fragt nach der Verbindung bei der Zertifizierungsstelle, welche die Unterschrift geleistet hat, nach, ob diese überhaupt noch gültig ist. Mit OCSP-Stapeling fordert unser Server regelmäßig eine kleine, unterschriebene „Notiz“ der Zertifizierungsstelle an, in welchem die Gültigkeit mit der aktuellen Uhrzeit hinterlegt ist. Diese senden wir gleich mit – ist dem Browser diese Info aktuell genug und die Unterschrift OK muss er nicht extra nochmal nachfragen.

    SSLUseStapling          on
    SSLStaplingResponderTimeout 5
    SSLStaplingReturnResponderErrors off

Letzter Punkt: HSTS – HTTP Strict Transport Security. Hiermit sagen wir dem Browser, dass wir für die nächste Zeit ausschließlich per HTTPS arbeiten wollen. Alle zukünfigen Zugriffe werden automatisch per HTTPS abgewickelt, auch wenn der Nutzer nicht per Hand https anfordert. Im Gegensatz zu den gängigen HTTP-Umleitungen spart es einen unverschlüsselten Request, welcher ggf. auch als Angriffspunkt dienen kann. Wenn man seine Webseite absichtlich per HTTP und HTTPS anbieten möchte sollte man den Header natürlich überspringen.

    # HSTS (mod_headers is required) (15768000 seconds = 6 months)
    Header always set Strict-Transport-Security "max-age=15768000"

Der Rest
Eine gute Ressource um zwischen Sicherheit und Kompatibilität abzuwähen oder die Konfiguration für andere Webserver und Funktionen anzupassen ist der Mozilla SSL Configuration Generator, auf dessen Ausgaben auch das hiesige Beispiel basiert.

Sollen alle Anfragen über HTTPS laufen kann man den HTTP-Listener anweisen für alle Anfragen mir einer Umleitung auf die HTTPS-Seite zu antworten. Hierzu reicht folgende Zeile im zuständigen VHost:

Redirect / https://testserver.adlerweb.info/

Wer testen möchte, ob alles Funktioniert hat und welche Geräte und Browser zu alt sind um auf die Webseite zugreifen zu können, kann die SSL-Tester von SSLLabs nutzen – dieser generiert einen ausführlichen und gut verständlichen Report und gibt weitere Tipps bei möglichen Problemen.