TLS-Konfigurationsprüfung
Liefert eine Live-Erstsicht auf Protokolle, Zertifikatsabgleich, SNI, ALPN, HSTS und grobe Cipher-Qualität.
Web-SicherheitTLS härten, ohne bei der Client-Kompatibilität zu raten
Eine starke TLS-Policy ist nicht das neueste Konfigurationsfragment, das du in einen Loadbalancer kopieren kannst. Sie ist die kleinste Protokollfläche, die deine gemessenen Clients zuverlässig nutzen — mit ausdrücklichen Ausnahmen, beobachtbaren Handshakes und einem Enddatum für jedes Zugeständnis an Altgeräte.
Erst die Clients, dann die Baseline
Für eine öffentliche Browser-Site sind TLS 1.2 und TLS 1.3 die vernünftige Basis. TLS 1.0 und 1.1 sind obsolet, scheitern an gängigen Sicherheitsvorgaben und überleben meist nur, weil niemand ihre Abschaltung nachgewiesen hat. Trotzdem hat nicht jeder Endpunkt dasselbe Publikum. Zahlungsterminals, Embedded Controller, Lagerscanner, Java-Runtimes und Partnerschnittstellen überdauern Browserannahmen gern um ein Jahrzehnt. Sie blind auszusperren ist keine Härtung, sondern ein Ausfall mit Sicherheitsetikett.
Segmentiere zuerst. Moderner öffentlicher Traffic bekommt einen modernen Endpunkt; wirklich nötige Altclients kommen auf einen separaten Host, Listener, Netzpfad oder Gateway mit engerem Zugriff und Ablöseplan. Schwäche nie die Haupt-Site, weil ein unbekanntes Gerät etwas „vielleicht“ braucht. Prüfe den benannten öffentlichen Endpunkt mit der TLS-Konfigurationsprüfung auf Protokollannahme, Zertifikatsnamen, SNI, ALPN, HSTS-Evidenz und grobe Cipher-Befunde. Das Ergebnis ist eine erste Beobachtung aus einem Blickwinkel, kein vollständiges Compliance-Audit. Für interne Gegenstellen brauchst du eine Probe aus dem erreichbaren Netz; ein öffentlicher Scanner kann private Adressen absichtlich nicht beurteilen.
Protokollversionen entfernen ganze Fehlerfamilien
Schalte SSLv2, SSLv3, TLS 1.0 und TLS 1.1 ab, sofern keine dokumentierte Ausnahme mit aktueller Evidenz und Besitzer existiert. TLS 1.3 ist nicht bloß TLS 1.2 mit neueren Ciphers: Es entfernt veraltete Verhandlungsoptionen, verschlüsselt mehr vom Handshake und begrenzt Cipher Suites auf moderne AEAD-Verfahren. TLS 1.2 bleibt für breite Kompatibilität, aber bewusst eingeschränkt. Die Untergrenze gehört auf jede terminierende Schicht — CDN, Ingress, Appliance, Service Mesh und Origin. Ein vergessener Alternativ-Listener bleibt Angriffsfläche.
Teste SNI und ALPN als Teil des Protokollverhaltens. Eine Verbindung zur IP kann den Default-VHost samt falschem Zertifikat zeigen, während echte Clients einen Hostnamen senden. Fehlendes ALPN bricht HTTPS gewöhnlich nicht; es verhindert still HTTP/2 und lässt den Verkehr auf HTTP/1.1. Prüfe außerdem IPv4 und IPv6, regionale Edges, wiederaufgenommene Verbindungen und relevante Dienste außerhalb von Port 443. „Im Browser an meinem Schreibtisch ging es“ beweist einen Pfad und einen Handshake — mehr nicht.
Cipher-Policy entscheidet vor allem bei TLS 1.2
TLS 1.3 stellt eine kurze standardisierte Familie von AEAD-Suites bereit; der Schlüsselaustausch wird getrennt konfiguriert. Lange kopierte Cipher-Strings betreffen vor allem TLS 1.2 und älter. Bevorzuge dort ECDHE mit AES-GCM oder ChaCha20-Poly1305, behalte ECDSA- und RSA-Authentisierung nur soweit Zertifikate und Clientbestand sie brauchen und entferne statischen RSA-Schlüsselaustausch, RC4, 3DES, Export-, anonyme und verbliebene Nicht-AEAD-Suites. Die Schreibweise hängt von der Bibliothek ab, die Sicherheitseigenschaft nicht.
Eine serverseitige Reihenfolge kann unter TLS 1.2 helfen, wenn alte Clients schwache und starke Optionen ungünstig anbieten. „Das Stärkste zuerst“ ist aber keine universelle Performance-Regel: Hardwarebeschleunigung begünstigt AES-GCM, mobile Geräte ohne sie fahren mit ChaCha20 oft besser. Unter TLS 1.3 verhandeln die Endpunkte gewöhnlich aus einer kleinen starken Menge. Halte die Policy lesbar. Eine 200 Zeichen lange Beschwörungsformel aus einem alten Blog ist kaum prüfbar und kann Ausschlüsse enthalten, deren Bedeutung sich mit OpenSSL-Versionen geändert hat.
Forward Secrecy ist eine Eigenschaft des Key Exchange
Forward Secrecy bedeutet, dass der spätere Verlust des langfristigen Zertifikatsschlüssels nicht rückwirkend aufgezeichnete Sitzungen entschlüsselt. Ephemeres Diffie-Hellman liefert diese Eigenschaft: ECDHE ist der Normalfall, TLS 1.3 nutzt beim regulären vollständigen Handshake ephemeren Austausch. Statischer RSA-Schlüsselaustausch tut es nicht. Ein RSA-Zertifikat kann sehr wohl in einer ECDHE-Suite arbeiten — es signiert den Austausch, zwingt ihn aber nicht in statisches RSA.
Nutze gepflegte Kurven wie X25519 und secp256r1 entsprechend Plattform und gemessenen Clients und überlasse den Rest möglichst den Defaults einer aktuellen Bibliothek. Eigene finite-field-DH-Parameter brauchen angemessene Größe und Pflege; schwache oder wiederverwendete Parameter entwerten eine ansonsten respektable Suite-Liste. Schütze Langzeitschlüssel bei passendem Risiko in kontrolliertem Keystore oder HSM, rotiere sie automatisiert und untersuche das Deployment mit dem SSL-Zertifikat-Decoder. Er zeigt Namen, Laufzeit, Algorithmen, Fingerprints, SPKI-Hashes, Extensions und präsentierte Kette, beansprucht aber keine Truststore- oder Widerrufsprüfung.
Resumption ist wertvoller Zustand mit Sicherheitslaufzeit
Session IDs und Session Tickets sparen Latenz und CPU, indem sie einen früheren Sicherheitskontext wiederaufnehmen. Damit entsteht Schlüsselmaterial, dessen Laufzeit und Verteilung zählen. Ein Ticket-Schlüssel, der unbegrenzt über eine ganze Flotte geteilt wird, schwächt Forward-Secrecy-Ziele und vergrößert den Schaden eines Diebstahls. Rotiere Ticket-Keys, begrenze ihre Gültigkeit, kontrolliere die empfangenden Nodes und verstehe das Verhalten bei Rolling Deployments. Wenn du gemeinsame Ticket-Schlüssel nicht sauber verwalten kannst, sind weniger Resumptions der ehrlichere Tausch.
Zero-Round-Trip-Daten in TLS 1.3 sind eine eigene Entscheidung. 0-RTT spart wiederkehrenden Clients Latenz, aber Early Data lässt sich durch Angreifer wiederholen, obwohl es auf dem Transport verschlüsselt bleibt. Erlaube es nur für Operationen, deren Wiederholung sicher und zustandslos ist; ein GET allein beweist das nicht. Login-Übergänge, Käufe, Zähler, signierte URLs und Rate-Limits können Seiteneffekte haben. Viele gewöhnliche Sites sollten 0-RTT ausgeschaltet lassen. Eine gesparte Runde rechtfertigt nicht automatisch ein neues Replay-Modell in der Anwendung.
Messen, eine Grenze ändern, Fehler beobachten
Beginne mit Handshake-Telemetrie: ausgehandelter TLS-Version, Cipher, SNI, ALPN, Clientfamilie im Rahmen deiner Datenschutzvorgaben, Fehlergrund und Endpunkt. Trenne Client-Inkompatibilität von Zertifikatsfehlern, Routing-Problemen und Applikations-Resets. Beobachte ein begrenztes Zeitfenster, identifiziere echte Legacy-Nutzung, finde die Besitzer und teste einen Canary-Endpunkt, bevor du die Untergrenze verschiebst. Synthetische Probes finden Konfigurationsdrift; echter Traffic zeigt, für wen du Kompatibilität bezahlst.
Nach dem Rollout beobachtest du Handshake-Fehler, Geschäftstransaktionen, Supportsignale und regionale Unterschiede. Halte einen schnellen Rollback bereit, aber lass ihn nicht versehentlich zur Dauer-Policy werden. Jede Ausnahme braucht Besitzer, begrenzten Endpunkt, kompensierende Kontrollen und Ablaufdatum. Dokumentiere auch, welche Metrik ihre Entfernung erlaubt; „noch kein Ticket“ ist kein belastbarer Kompatibilitätsnachweis. Verwendet der Dienst DNSSEC-authentisierte TLSA-Policy, prüft der DANE-Validator Owner-Namen, TLSA-Syntax, DNSSEC-Kontext und optional den Zertifikatsabgleich. Ein Zertifikats- oder Schlüsselwechsel kann DANE-validierende Clients brechen, während klassische PKI zufrieden bleibt. Härtung gelingt, wenn die gemessene Angriffsfläche schrumpft und die Abhängigkeitskarte klarer wird.