8. November 2017

Episode 6: TR-02102-2 und der Apache Tomcat Anwendungsserver

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

Diese Episode beschäftigt sich mit der TLS-Konfiguration des Anwendungsservers Apache Tomcat.

Wie in den letzten Episoden möchte ich auch in dieser zuerst 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. Grundsätzlich sollte die Umsetzung gut geplant und hinreichend getestet werden, ob Kompatibilität der Konsumenten gewährleistet ist.

Wie setzt man die TR mit dem Apache Tomcat technisch um?

Zunächst einmal sind zwei wichtige Faktoren zu beachten:

  1. Welche Apache Tomcat Version / welcher Branch befindet sich im Einsatz?
  2. Welcher Connector-Typ wird verwendet und welche Engine verwendet dieser?

Denn davon hängt letztlich die Konfiguration ab. Ein NIO-Connector möchte anders konfiguriert werden, als beispielsweise ein APR-Connector. Genaueres sollte man daher der Tomcat Dokumentation der entsprechenden Serverversion und des Connectors entnehmen.

Für einen Tomcat 8.5 mit APR-Connector mit OpenSSL wird die Connector-Config in der Server.xml wiefolgt angepasst:

<SSLHostConfig honorCipherOrder="true" disableCompression=“true“
protocols="TLSv1.2"
ciphers="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" >
<Certificate certificateFile="conf/Serverzertifikat.pem" certificateChainFile=conf/Zertifikatskettendatei.pem” certificateKeyFile=”conf/Zertifikat.key” certificateKeyPassword=”SicheresKennwortFuerDasZertifikatHierEinfuegen” />
</SSLHostConfig>

 

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:
| SSLv2: No supported ciphers found
| SSLv3: No supported ciphers found
| TLSv1.0: No supported ciphers found
| TLSv1.1: No supported ciphers found
| TLSv1.2:
| ciphers:
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (dh 2048) - A
| TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (dh 2048) - A
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (dh 2048) - A
| TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (dh 2048) - A
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256k1) - A
| TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256k1) - A
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256k1) - A
| TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256k1) - A
| compressors:
| NULL
| cipher preference: server
|_ least strength: A

Und was bedeutet das für die Kompatibilität mit anderen Systemen?

Nur Systeme, die TLSv1.2 sprechen können, sind in der Lage, sich mit dem Server zu verbinden. Welche das sind steht in Episode 2 beim Apache unten aufgelistet.