Administration / Webmaster, German, IT-Security, Linux

Optimale TLS-Sicherheit mit Abwärtskompatibilität für Apache bei Qualys SSL Labs und co.

Viele kennen sicherlich den SSL Report von Qualys SSL Labs. Nun möchte man natürlich gute Ergebnisse bzgl. Sicherheit erzielen, aber kann auch nicht die Abwärtskompatibilität völlig außer Acht lassen. Ich versuche hier einen nach aktuellem Stand guten Trade-Off vorzustellen. Außerdem möchten wir auch im CryptCheck, ImmuniWeb SSL Security Test, DigiCert® SSL Installation Diagnostics Tool und SSL-Tools Check gut abschneiden. In diesem Tutorial setze ich auf Debain, apache2 und certbot. Ähnliches lässt sich natürlich auch mit nginx und/oder acme.sh erreichen.

Grundlage für diesen Artikel war folgende Konfiguration:

  • Debian 10
  • Apache 2.4.38 (Befehl: apache2 -v)
  • certbot 0.31.0 (Befehl: certbot --version)
  • openssl 1.1.1d (Befehl: openssl version)

Zertifikat mit certbot erzeugen

Wer certbot noch nicht installiert hat, möge das nach der einfachen Anleitung auf der certbot-Homepage tun. Kommen wir nun erst mal zur Generierung und der Installation des Zertifikats. Während sich Qualys mit 2048 Bit RSA Zertifikaten zufrieden gibt, erhalten wir bei CryptCheck damit nur eine durchschnittliche Bewertung. Für den RSA Schlüssel empfiehlt das BSI (Bundesamt für Sicherheit in der Informationstechnik) noch bis Ende 2023 eine Schlüssellänge von 2048 Bits, die als sicher gelte. Danach werden 3072 Bits empfohlen. Nachzulesen in der Sicherheitsrichtlinie BSI TR-02102-1 (Stand: 24. März 2020). Wir wählen hier 3072 Bits, weil das einem guten Kompromiss aus Sicherheit und Performance entspricht (Paramater --rsa-key-size 3072). Wer noch eins drauf setzten möchte, kann natürlich auch 4096 Bits nehmen.

Auf jeden Fall benötigen wir noch HTTP Strict Transport Security (HSTS). Dabei handelt es such um einen HTTP Header, der z.B. durch Apache gesetzt werden kann, und aussagt, dass diese Seite (für einen sehr langen Zeitraum) vom Browser nur noch per https aufgerufen werden darf. Unverschlüsselter Datenverkehr wird also für die Zukunft ausgeschlossen. Der Paramater lautet --hsts. Außerdem sollten wir eine Weiterleitung von http auf https einrichten. Auch das tut certbot für uns (Paramater --redirect). Der Befehl lautet also wie folgt:

certbot --apache --rsa-key-size 3072 --hsts --redirect

Wahl der Protokolle und Cipher-Suites

certbot hat nun für uns die Datei /etc/letsencrypt/options-ssl-apache.conf erzeugt, die wie wie folgt editieren:

SSLEngine on

# Intermediate configuration, tweak to your needs
SSLProtocol             all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite          ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384
SSLHonorCipherOrder     on
SSLCompression          off

Als SSL-Protokolle müssen wir in jedem Fall TLS 1.0 und TLS 1.1 herausnehmen, da wir seit Januar 2020 bei Qualys auf Grad B gestutzt werden. Es verbleiben die sicheren Versionen TLS 1.2 und TLS 1.3. Diese Protokolle gelten als nicht mehr hinreichend sicher. Die Wahl der Chipher-Suits war eine lange Suche und ausprobieren. Sie sorgen in Qualys dafür, dass wir einen sehr guten A+ Rank erhalten, aber keine Hanshake Simulation fehlschlägt. Auch ImmuniWeb verpasst uns einen A+ Rank. Auch bei CryptCheck erhalten wir eine A+ Raking mit 93/100 Punkten. Hätten wir RSA mit 4096 Bits genutzt, wäre CryptCheck mit 96/100 Punkten übrigens noch ein bisschen Glücklicher gewesen, weil wir 100/100 beim Schlüsselaustausch bekommen hätten. Ich halte das allerdings für etwas übertrieben.

A+ Ranking beim SSL Report von Qualys SSL Labs
A+ Ranking mit 93/100 Punkten bei CryptCheck mit 3072 Bit Zertifikat
A+ Ranking bei CryptCheck mit 96/100 Punkten mit 4096 Bit Zertifikat
A+ Rank beim ImmuniWeb SSL Security Test

Und darüber hinaus?

Abschließend sollte man noch mal über DNS Certification Authority Authorization nachdenken. Der Folgende DNS Eintrag besagt, dass unser Zertifikat von Let’s Encrypt stammen muss und sorgt so für noch etwas mehr Sicherheit:

the-digital-native.de. CAA 128 issue "letsencrypt.org"

Wir haben es also geschafft: Ein Top Security Rank in allen mir bekannten Tests. Wer jetzt noch etwas mehr tun möchte, kann sich noch über DANE bzw. einen TLSA DNS-Eintrag Gedanken machen. Hier wird ein Hash des eigenen Zertifikats als DNS Eintrag hinterlegt, sodass das Zertifikat nicht unbemerkt ausgetauscht werden kann. Hier gibt es einen Generator dafür.

Auch einen Blick wert ist das Mozilla Obversatory, welches einem vor allem Vorschläge für diverse HTTP-Header macht. Für einfache Seiten ist dies relativ einfach umzusetzen, aber für CMS Software wie WordPress wird es schon schwieriger. In einem zukünftigen Artikel habe ich vor, mich mit dem Content Security Policy Header für WordPress zu beschäftigen. Stay Tuned!