1. Juli 2016

Episode 2 – TR-02102-2 und der Apache HTTP Server

Dieser Blog Post ist Teil der Blogserie zur TLS-Konfiguration – Technische Richtlinie TR-02102-2 des BSI.

In Episode 1 habe ich erläutert, was der Richtlinie zweiter Teil empfiehlt. In dieser Episode möchte ich veranschaulichen, wie man das mit einem zum Zeitpunkt der Erstellung dieses Dokuments aktuellen Apache Webserver umsetzt.

Ich möchte ausdrücklich darauf hinweisen, dass es eine Möglichkeit und nicht DIE LÖSUNG ist. Da sich die Welt zum Glück ständig dreht, können sich die nachfolgenden Informationen im Laufe der Zeit überholen. Wann immer jemand einen Fehler entdeckt oder eine Vereinfachung kennt, darf er sich gerne an uns wenden.

Kritikern, die sagen, dass durch die richtlinienkonforme Einstellung die (Abwärts-)Kompatibilität flöten geht, sei folgendes mit auf den Weg gegeben: Sie haben nur bedingt recht. Z. B. wenn man abwärtskompatibel bis in die Windows NT-Zeit bleiben muss. Wenn man aber niemals den ersten Schritt in eine neue, sichere Richtung geht, dann wird sich (so schnell) nichts verbessern.

Auf der Suche, ob sich jemand bereits die Mühen gemacht hat, die Empfehlungen der TR mal umzusetzen, bin ich leider auf wenig Referenzen gestoßen. Jedoch macht sich ein Mensch gute Gedanken in einem Tutorial zum Thema sicherer Transportverschlüsselung. Ich reflektiere das daher mal auf die TR.

Wie setzt man die TR mit dem Apache technisch um?

Endlich wird’s technisch! Aber da die Vielfalt so groß ist, werde ich nach und nach weit verbreitete Technologien aufbereiten.

Da Ubuntu eins meiner liebsten Betriebssysteme ist und der Apache auch sehr verbreitet ist, macht nachfolgende Konfigurationsanleitung den Anfang. Das bezieht sich also auf ein halbwegs aktuelles Ubuntu (in meinem Fall ein 14.04.3 LTS, das mit einem Apache 2.4.7 und OpenSSL 1.0.1f daher kommt – Anmerkung: Dies bezog sich auf die Urfassung des Artikels vom Juni 2016), um die Transportverschlüsselung entsprechend der TR zu konfigurieren. Dabei möchte ich ausschließlich Perfect Forward Secrecy berücksichtigen.

Update aus Juni 2022: da sich sowohl die TR, als auch die Apache-Konfiguration inzwischen geändert haben, wurde die nachfolgende Konfiguration aktualisiert und auf einem Ubuntu 20.04 mit openssl 1.1.1f

Apache2 mit mod_ssl, PFS, aber ohne Cipher Suites mit Pre-Shared Key:

openssl dhparam -out /etc/ssl/private/dhparams.pem 4096

in der Apache-Konfiguration des Moduls mod_ssl folgendes ergänzen:

SSLOpenSSLConfCmd DHParameters "/etc/ssl/private/dhparams.pem”
Require SSL
SSLProtocol -ALL +TLSv1.3 +TLSv1.2
SSLCompression Off
SSLHonorCipherOrder on
SSLCipherSuite 'ECDHE-ECDSA-AES128-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-DSS-AES128-SHA256:DHE-DSS-AES128-GCM-SHA256:DHE-DSS-AES256-SHA256:DHE-DSS-AES256-GCM-SHA384:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-GCM-SHA384'
SSLCipherSuite TLSv1.3 'TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_AES_128_CCM_SHA256'
SSLOpenSSLConfCmd ECDHParameters automatic
SSLOpenSSLConfCmd Curves brainpoolP512r1:brainpoolP384r1:brainpoolP256r1:secp521r1:secp384r1

Untersucht man nun die Cipher-Konfigration von außen, erhält man mit nmap und dem Script ssl-enum-ciphers auf demselben System folgendes Ergebnis:

| ssl-enum-ciphers:
| TLSv1.2:
| ciphers:
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp384r1) - A
| TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp384r1) - A
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp384r1) - A
| TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp384r1) - A
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (dh 4096) - A
| TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (dh 4096) - A
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (dh 4096) - A
| TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (dh 4096) - A
| compressors:
| NULL
| cipher preference: server
| TLSv1.3:
| ciphers:
| TLS_AKE_WITH_AES_128_GCM_SHA256 (secp384r1) - A
| TLS_AKE_WITH_AES_256_GCM_SHA384 (secp384r1) - A
| TLS_AKE_WITH_AES_128_CCM_SHA256 (secp384r1) - A
| cipher preference: server
|_ least strength: A

Leider nimmt der Apache dann die Cipher Suites mit DHE-DSS aus mir nicht erklärlichen und mit vertretbarem Aufwand nachprüfbar aus dem Programm.

Was bedeutet das im Bezug auf Kompatibilität mit älteren Systemen?

In einer idealen Welt existieren keine älteren Systeme und keine, die nur schwache kryptografische Algorithmen zulassen. In der realen Welt jedoch schon. Wenn man die Empfehlungen der TR umsetzt, sperrt man generell Clients aus, die Kein TLS 1.2 können.

Nachfolgend aufgelistete Clients können kein TLS 1.2 (die Liste erhebt keinen Anspruch auf Vollständigkeit und Richtigkeit, sondern besteht aus zusammengetragenen, nicht selbst getesteten Informationen):

  • Android vor 4.4
  • Chrome vor Version 30 (plattformunabhängig)
  • Firefox älter als Version 27 auf Win7/8
  • IE bis Version 10 auf Win7, IE auf XP
  • Java 6
  • Java 7
  • Safari < Version 7
  • OpenSSL vor 0.9.8y