Transportsicherheit

Melina soll das neue Kundenportal der NovaHealth Solutions AG absichern. Als Erstes schaut sie sich an, wie die Verbindung zwischen Browser und Server geschützt ist.

Die Grundlagen von TLS und Verschlüsselung kennst du bereits aus den vorherigen Modulen. Hier konzentrieren wir uns darauf, wie du TLS für eine Webanwendung richtig konfigurierst. Eine falsche oder unsichere Konfiguration kann die Verschlüsselung wirkungslos machen.

💡 Transportsicherheit heißt: Nicht nur verschlüsseln, sondern richtig konfigurieren. Die Stärke der Verbindung bestimmt die Konfiguration. Grundlegend gilt aber: Jede Webanwendung muss über HTTPS erreichbar sein ohne Ausnahme.

TLS: Versionen und Konfiguration

• TLS 1.2: Aktueller Mindeststandard. Sicher bei korrekter Cipher-Suite-Konfiguration.
• TLS 1.3: Empfohlener Standard. Schnellerer Handshake, nur noch sichere Algorithmen, Perfect Forward Secrecy ist erzwungen.
• TLS 1.0 und 1.1: Veraltet und unsicher. Diese Versionen müssen deaktiviert sein.
• SSLv3: Extrem unsicher, sollte schon lange von TLS abgelöst sein. Spätestens seit dem POODLE-Angriff in 2014 entgültig unsicher.

💡Wer es genau wissen will: Empfehlungen vom BSI zum Thema TLS und den verschiedenen Modi können hier nachgelesen werden: https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102-2.pdf?__blob=publicationFile&v=14

Cipher Suites richtig konfigurieren

Eine Cipher Suite ist das Paket kryptografischer Algorithmen, auf das sich Client und Server beim TLS-Handshake einigen. Schauen wir uns ein Beispiel an:

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

Was bedeuten die einzelnen Bestandteile?

• ECDHE: Schlüsselaustauschverfahren (Elliptic Curve Diffie-Hellman Ephemeral), sorgt für Perfect Forward Secrecy
• RSA: Authentifizierungsverfahren, mit dem der Server seine Identität nachweist
• AES_256_GCM: Verschlüsselungsalgorithmus (AES mit 256 Bit Schlüssellänge im GCM-Modus)
• SHA384: Hash-Algorithmus für die Integritätsprüfung

Auch bei Cipher Suites gibt es veraltete und kryptografisch schwache Verfahren, die deaktiviert sein müssen:

• RC4: Bekannte kryptografische Schwächen
• 3DES: Zu kurze Blocklänge, veraltet
• NULL-Cipher: Keine Verschlüsselung
• EXPORT-Cipher: Absichtlich geschwächt

✅ Faustregel: TLS 1.3 verwenden, wo möglich. TLS 1.3 erlaubt nur noch sichere Cipher Suites und das Problem der falschen Konfiguration entfällt damit.

Praxistipp

Suchen wir die Konfigurationen einmal am Beispiel eines Apache2 Servers, der Zertifikate mit Let’s Encrpyt konfiguriert hat.

Dein Server kann natürlich davon abweichen, aber die generelle Konfiguration ist in der Regel irgendwo unter /etc/apache2/sites-available/*.conf zu finden. In der Config dort gibt es eine Zeile wie z.B. Include /etc/letsencrypt/options-ssl-apache.conf, die auf die Let’s Encrypt Konfiguration verweist. Diese Konfiguration kann zum Beispiel so aussehen:

# This file contains important security parameters. If you modify this file
# manually, Certbot will be unable to automatically provide future security
# updates. Instead, Certbot will print and log an error message with a path to
# the up-to-date file that you will need to refer to when manually updating
# this file. Contents are based on https://ssl-config.mozilla.org

SSLEngine on

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

SSLOptions +StrictRequire

# Add vhost name to log entries:
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\"" vhost_combined
LogFormat "%v %h %l %u %t \"%r\" %>s %b" vhost_common

Die Zeile SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1 besagt durch das Minus davor, dass alle alten Verfahren deaktiviert sind. TLS 1.3 ist nicht explizit konfiguriert, was bedeutet, dass es erlaubt ist, falls es der Apache/OpenSSL auf diesem Server unterstützt

Die Zeile darunter listet alle erlaubten Ciphers auf. Hier aber vorallem welche, die zu TLS 1.2 gehören. Das neuere Verschlüsselungsverfahren 1.3 nutzt nochmal andere Ciphers.

Eine mögliche Härtung wäre jetzt zum Beispiel TLS 1.3 hinzuzufügen. Dafür sollte man aber nicht in der Config von Let’s Encrpyt herumpfuschen, da diese automatisch erstellt wird und Änderungen möglicherweise wieder verloren gehen. Lege lieber eine neue Datei an und lade sie mit einem Include-Befehl. Zunächst erstellst du mit Nano die betreffende Datei: nano /etc/apache2/myconfig/tls-hardening.conf. Dann könnte eine gehärtete Config folgendermaßen aussehen:

SSLProtocol -all +TLSv1.2 +TLSv1.3

SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305

SSLHonorCipherOrder off
SSLSessionTickets off
SSLCompression off

Es sind jetzt explizit alle deaktiviert (-all), außer TLSv1.2 und TLSv1.3, die gezielt aktiviert wurden. Außerdem wurden die beiden DHE-RSA-* Ciphern raus genommen. Nicht weil sie unsicher sind, sondern weil ECDHE-* heute normalerweise bevorzugt, schneller und sauberer ist. Für normale Webserver braucht man die DHE-RSA-* meist nicht.

HSTS: HTTPS erzwingen

HSTS (HTTP Strict Transport Security) weist den Browser an, eine Website ausschließlich über HTTPS aufzurufen. Dazu wird im HTTP Response Header vom Server z.B. folgendes zurückgeliefert:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Die einzelnen Direktiven haben folgende Bedeutung:

• max-age=31536000: Der Browser merkt sich für 31.536.000 Sekunden (= 1 Jahr), dass diese Website nur über HTTPS aufgerufen werden darf
• includeSubDomains: Die Regel gilt auch für alle Subdomains (z.B. portal.novahealth-solutions.de)
• preload: Die Domain wird in die HSTS-Preload-Liste der Browser aufgenommen (siehe unten)

Warum ist HSTS so wichtig? Ohne HSTS ist ein SSL-Stripping-Angriff möglich: Ein Angreifer in einer Man-in-the-Middle-Position (z.B. in einem öffentlichen WLAN) fängt den ersten HTTP-Request des Benutzers ab und verhindert das Upgrade auf HTTPS. Der Benutzer kommuniziert dann unverschlüsselt weiter, vermutlich ohne es zu merken.

HSTS Preload

Mit der preload-Direktive wird die Domain in die HSTS-Preload-Liste der Browser eingetragen. Diese Liste ist fest in Chrome, Firefox und anderen Browsern eingebaut. Das bedeutet: HTTPS wird bereits beim allerersten Aufruf erzwungen, noch bevor der Browser den Server jemals kontaktiert hat. Das reduziert Angriffsfläche bei erstmaligem Aufruf einer Website, weil der Browser ansonsten darauf angewiesen ist, die obige HSTS-Anweisung vom Server erst einmal zu erhalten.

Die folgende Abbildung zeigt das Prinzip. Maximiere die Abbildung für bessere Lesbarkeit:

Merksatz: HSTS sagt dem Browser „Sprich mit mir nur noch über HTTPS“ und Preload sorgt dafür, dass der Browser das schon weiß, bevor er die Website zum ersten Mal besucht.

Praxistipp

Den HSTS Header kannst du ebenfalls in der Apache-Konfiguration setzen. Um das Header-Modul zu laden, muss folgendes Kommando ausgeführt werden:

sudo a2enmod headers

Anschließend kann zum Beispiel Header always set Strict-Transport-Security "max-age=31536000" in die Config eingetragen werden. max-age=31536000 bedeutet: Browser sollen sich für ein Jahr merken, dass die Seite nur noch per HTTPS aufgerufen werden soll. Das sieht dann in etwa so aus:

<IfModule mod_ssl.c>
<VirtualHost *:443>
    ServerAdmin mail@novahealth-solutioins.de
    ServerName novahealth-solutions.de
    DocumentRoot /var/www/novahealth-solutions.de
    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined

    Include /etc/letsencrypt/options-ssl-apache.conf
    Include /etc/apache2/myconfig/tls-hardening.conf    
    Header always set Strict-Transport-Security "max-age=31536000"

    SSLCertificateFile /etc/letsencrypt/live/novahealth.com/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/novahealth.com/privkey.pem
</VirtualHost>
</IfModule>

Anschließend gibst du den folgenden Befehl ein, um die Konfiguration zu prüfen:

sudo apache2ctl configtest

Nun fehlt noch der Reload der Konfiguration, damit die Konfiguration aktiv wird:

sudo systemctl reload apache2

Zertifikatsmanagement

Um die Sicherheit über die Zeit nicht wieder aufzuweichen, ist ein sauberes Zertifikatsmanagement entscheidend.

• Zertifikate rechtzeitig erneuern: Abgelaufene Zertifikate führen zu Browser-Warnungen und Vertrauensverlust. Let’s Encrypt ist eine kostenlose Zertifizierungsstelle (CA), die über das ACME-Protokoll (Automatic Certificate Management Environment) eine vollautomatische Ausstellung und Erneuerung von TLS-Zertifikaten ermöglicht. Das ist heute der Standard für die meisten Webanwendungen.
• Vollständige Zertifikatskette liefern: Der Server muss alle Zwischenzertifikate (Intermediate Certificates) mitsenden, damit der Browser die Kette bis zur vertrauenswürdigen Root-CA nachvollziehen kann. Eine unvollständige Kette führt bei manchen Clients zu Fehlern. Du kennst das Konzept der Zertifikatskette aus Modul B3.
• Certificate Transparency (CT): Öffentliche Logs, in denen alle ausgestellten Zertifikate verzeichnet werden. Domain-Inhaber können überwachen, ob jemand unbefugt Zertifikate für ihre Domain ausstellt.

Überprüfe, ob du die Grundlagen der Transportsicherheit drauf hast.