Wie deaktiviert man veraltete TLS-Protokolle in einer HTTPS-konformen Konfiguration?

Eine gängige Maßnahme zur HTTPS-Konformität besteht darin, TLS 1.0, TLS 1.1 und ältere SSL-Protokolle zu deaktivieren, TLS 1.2 beizubehalten und TLS 1.3 zu aktivieren, sofern es serverseitig unterstützt wird. Ob dies den Anforderungen entspricht, hängt jedoch auch von der geltenden Sicherheitsbaseline, den Cipher Suites, den Zertifikaten und dem tatsächlichen Geltungsbereich ab. Die Protokollversion allein reicht für eine Beurteilung nicht aus.

Klären Sie vorab, wo die TLS-Verbindung des Browsers tatsächlich terminiert. Wird die Website über ein CDN, eine WAF oder einen Load Balancer bereitgestellt, akzeptiert der öffentlich erreichbare Einstieg möglicherweise weiterhin ältere Protokolle, wenn nur die Konfiguration des Ursprungsservers geändert wird.

Alle HTTPS-Einstiegspunkte ermitteln, die angepasst werden müssen

Unternehmenswebsites für den Außenhandel, grenzüberschreitende Shops und Werbe-Landingpages nutzen häufig eine Zugriffskette nach dem Muster „Besucher – CDN/WAF – Load Balancer – Ursprungsserver“. Jede TLS-Verbindung, die eigenständig aufgebaut wird, verfügt über eigene Protokolleinstellungen. Leitet ein zwischengeschaltetes Gerät den Datenverkehr lediglich weiter, steuert die Komponente, an der TLS tatsächlich terminiert, die Einstellungen.

Es empfiehlt sich, die Prüfung nach Domain und Listening-Port zu strukturieren und nicht nur nach der Anzahl der Server:

• Öffentlich erreichbare Einstiegspunkte: Hauptdomain, www-Subdomains, mehrsprachige Websites, Shops, APIs und Werbe-Landingpages.
• Verbindungen zum Ursprungsserver: HTTPS-Verbindungen zwischen CDN und Load Balancer sowie zwischen Reverse-Proxy und Anwendungsserver.
• Zusätzliche Einstiegspunkte: direkt erreichbare Ursprungsserver-Adressen, Ausweichdomains, Verwaltungszugänge und weitere HTTPS-Ports.

Die Einstellung „Minimale TLS-Version“ eines CDN steuert in der Regel die Verbindung der Besucher. Das Protokoll für die Verbindung zum Ursprungsserver muss separat konfiguriert werden. Wird für diese Verbindung weiterhin HTTP verwendet, lässt sich aus einem erfolgreichen öffentlichen Test nicht schließen, dass die gesamte Verbindungskette verschlüsselt ist.

Bei der Konfiguration ausdrücklich festlegen, welche Protokolle zulässig sind

Statt ältere Versionen einzeln auszuschließen, ist es klarer, die zulässigen Protokolle ausdrücklich aufzuführen. Vergewissern Sie sich vor der Konfiguration, dass der Webserver und die verwendete TLS-Bibliothek die gewünschten Versionen unterstützen. TLS 1.3 in die Konfigurationsdatei einzutragen bedeutet nicht, dass die aktuelle Umgebung dieses Protokoll auch bereitstellen kann.

Konfigurationsbeispiel für Nginx

Legen Sie die Einstellung im passenden Konfigurationskontext fest:

ssl_protocols TLSv1.2 TLSv1.3;

Wenn für alle Websites dieselbe Richtlinie gilt, können Sie die Einstellung zentral auf der Ebene http verwalten und prüfen, ob einzelne server-Blöcke abweichende Einstellungen enthalten. Werden mehrere virtuelle HTTPS-Hosts über dieselbe Adresse und denselben Port bereitgestellt, prüfen Sie auch den Standard-Host: Die Protokollverhandlung kann von dessen Konfiguration beeinflusst werden. Es genügt daher nicht, nur den Konfigurationsblock der betreffenden Domain zu ändern.

Prüfen Sie nach dem Speichern zunächst die Syntax und laden Sie den Dienst anschließend neu:

nginx -t
nginx -s reload

Führen Sie das Neuladen nur nach erfolgreicher Syntaxprüfung aus. Aktualisieren Sie Container, Cluster und verwaltete Umgebungen über den jeweils vorgesehenen Bereitstellungsprozess. Stellen Sie sicher, dass alle Instanzen dieselbe Konfiguration verwenden, damit Anfragen nicht teilweise weiterhin bei älteren Knoten landen.

Vorgehen bei Apache und verwalteten Plattformen

Bei Apache lässt sich das Protokoll mit der Direktive SSLProtocol einschränken. In Umgebungen, die die entsprechenden Versionen unterstützen, kann beispielsweise folgende Einstellung verwendet werden:

SSLProtocol -all +TLSv1.2 +TLSv1.3

Prüfen Sie außerdem die globalen Einstellungen, die Konfiguration der virtuellen Hosts und die zugehörigen Vererbungsbeziehungen. Bei einem CDN, einem Cloud-Load-Balancer oder einer SaaS-Website-Plattform muss die Mindestversion in der Konsole der Komponente angepasst werden, die TLS tatsächlich verarbeitet. Prüfen Sie die Verbindungen der Besucher und zum Ursprungsserver jeweils separat.

In Nutzungsszenarien mit einer integrierten Plattform für Website-Erstellung und Marketingservices wie 易营宝 können Website-Seiten, Marketingdomains, CDN und Ursprungsserver von unterschiedlichen Verantwortlichen betreut werden. Legen Sie vor der Umsetzung fest, wer für die Konfiguration der einzelnen Einstiegspunkte zuständig ist und wie diese überprüft werden. Die Aussage „Die Plattform hat ein Zertifikat eingerichtet“ bedeutet nicht, dass ältere Protokolle an allen Einstiegspunkten deaktiviert sind.

Die Überprüfung muss belegen, dass alte Versionen abgewiesen werden und neue Versionen funktionieren

Dass sich eine Website im Browser öffnen lässt, zeigt lediglich, dass die Aushandlung eines Protokolls erfolgreich war. Es beweist nicht, dass ältere Versionen deaktiviert sind. Führen Sie für dieselbe Domain jeweils einen Handshake mit der angegebenen Version aus:

openssl s_client -connect example.com:443 -servername example.com -tls1
openssl s_client -connect example.com:443 -servername example.com -tls1_1
openssl s_client -connect example.com:443 -servername example.com -tls1_2
openssl s_client -connect example.com:443 -servername example.com -tls1_3

Ersetzen Sie die Beispieldomain durch die tatsächliche Domain. TLS 1.0 und TLS 1.1 sollten den Handshake nicht abschließen können, TLS 1.2 sollte funktionieren. Wenn TLS 1.3 angeboten werden soll, überprüfen Sie auch, ob der Handshake mit dieser Version erfolgreich ist. -servername übermittelt den SNI-Wert, damit die Anfrage nicht beim falschen virtuellen Host landet.

Ein Fehler beim Test älterer Protokolle bedeutet nicht zwangsläufig, dass der Server sie abweist. OpenSSL auf dem lokalen Rechner kann ältere Protokolle bereits deaktiviert haben oder über keine geeigneten älteren Cipher Suites verfügen. Scheitert der Client, bevor er den Handshake sendet, ist das kein Beleg dafür, dass der Server die Verbindung unterbindet. Berücksichtigen Sie die Fehlermeldung und verifizieren Sie das Ergebnis zusätzlich mit einem TLS-Scan-Tool, das die entsprechenden Prüfungen durchführen kann.

Prüfen Sie die öffentliche Domain und den Ursprungsserver separat. Um den Ursprungsserver direkt aufzurufen, ersetzen Sie -connect durch die IP-Adresse des Ursprungsservers und geben Sie die Domain weiterhin mit -servername an. Berücksichtigen Sie außerdem IPv4, IPv6, Ausweichzugänge und unterschiedliche Bereitstellungsknoten. Dokumentieren Sie Prüfzeitpunkt, Zieladresse und ausgehandelte Ergebnisse, damit die Abnahme und spätere Fehlersuche nachvollziehbar sind.

Die Kompatibilität anhand der Geschäftsabläufe überprüfen

Ältere Betriebssysteme, eingebettete Geräte oder seit längerer Zeit nicht aktualisierte API-Clients können nach der Änderung möglicherweise keine Verbindung mehr herstellen. Ermitteln Sie vor der Einführung anhand von Verbindungsprotokollen, einer Liste der aufrufenden Systeme und Geschäftstests, welche Abhängigkeiten bestehen. Prüfen Sie insbesondere das Absenden von Anfragen, Zahlungsweiterleitungen, Bestellrückmeldungen, Marketingdatenschnittstellen und Synchronisierungsaufgaben von Drittanbietern.

Kompatibilitätsprobleme sollten vorrangig durch die Aktualisierung des Clients, der Laufzeitumgebung oder der Schnittstellenkomponente behoben werden. Falls eine Übergangszeit erforderlich ist, kann ein separater, isolierter Einstiegspunkt in Betracht gezogen werden; beschränken Sie dessen Zugriffsbereich und legen Sie einen eindeutigen Abschalttermin fest. Aktivieren Sie nicht die älteren Protokolle für die gesamte Hauptwebsite, nur um einen einzelnen alten Aufrufer zu unterstützen. Beobachten Sie während der schrittweisen Einführung Handshake-Fehler, fehlgeschlagene Rückmeldungen und die Ergebnisse wichtiger Formulare. Dass eine Seite geöffnet werden kann, bedeutet nicht, dass Transaktions- oder Leadgenerierungsabläufe funktionieren.

Die Deaktivierung älterer TLS-Versionen ist nicht die gesamte HTTPS-Arbeit. Auch unter TLS 1.2 müssen Cipher Suites überprüft werden. Zertifikatskette, Domainübereinstimmung, Ablaufverwaltung und gemischte Inhalte sind ebenfalls separat zu behandeln. HTTP-Weiterleitungen und HSTS erfüllen jeweils eigene Aufgaben und ersetzen keine Protokollbeschränkungen. Halten Sie bei der Übergabe außerdem eine Liste der Einstiegspunkte, die wirksame Konfiguration und die Prüfnachweise fest. Prüfen Sie neu hinzugefügte Marketingdomains und CDN-Migrationen künftig anhand derselben Baseline.