SSL/TLS-Fehlkonfigurationen, die Ihre Site gefährden

Für die meisten Besucher ist HTTPS binär — das Schloss ist da oder nicht. Für einen Angreifer ist TLS ein Spektrum. Ein Zertifikat kann gültig und vertrauenswürdig sein, während die Konfiguration dahinter noch Downgrade-Angriffe erlaubt, über Subdomains leakt oder nächsten Monat beim Ablauf still bricht. Hier ist, wonach ein Scan jenseits von „ist es HTTPS“ sucht.

Zertifikate, die bald ablaufen

Ablauf ist der häufigste und vermeidbarste TLS-Vorfall. Da Zertifikatslaufzeiten schrumpfen, ist manuelle Erneuerung nicht mehr realistisch. Automatisieren Sie Ausstellung und Erneuerung (ACME / Let's Encrypt oder die verwalteten Zertifikate Ihrer Plattform) und warnen Sie deutlich vor dem Ablaufdatum, nicht erst am Tag selbst. Ein Scan zeigt die verbleibenden Tage, damit ein kurzlebiges Zertifikat Sie nicht überrascht.

Unvollständige Zertifikatsketten

Ein Server, der sein Leaf-Zertifikat sendet, aber das Zwischenzertifikat weglässt, funktioniert in Ihrem Browser — weil dieser das Zwischenzertifikat bereits zwischengespeichert hat — und schlägt bei anderen fehl. Das ist der klassische „bei mir läuft’s“-TLS-Bug. Liefern Sie immer die vollständige Kette:

openssl s_client -connect example.com:443 -servername example.com -showcerts

Zeigt die Ausgabe nur ein Zertifikat, ist Ihre Kette unvollständig.

Weiterhin aktivierte schwache Protokolle und Chiffren

TLS 1.0 und 1.1 sind veraltet und sollten deaktiviert werden; ebenso Export-Grade- und RC4-Chiffren. Moderne Empfehlung:

• Nur TLS 1.2 und TLS 1.3 unterstützen.
• Suiten mit Forward Secrecy (ECDHE) bevorzugen.
• RC4, 3DES und alles mit EXPORT deaktivieren.
• OCSP-Stapling aktivieren, um Sperrprüfungen zu beschleunigen.

Gemischte Inhalte auf HTTPS-Seiten

Eine HTTPS-Seite, die ein Skript, ein Stylesheet oder ein Bild über http:// lädt, gibt einem Angreifer Halt auf einer eigentlich sicheren Seite — und der Browser blockiert die aktiven Teile ohnehin und bricht Ihre UI. Finden und beheben Sie jede absolute http://-Referenz oder lassen Sie den Browser sie hochstufen:

Content-Security-Policy: upgrade-insecure-requests

Keine Weiterleitung von HTTP zu HTTPS

Wenn http://yoursite.com Inhalte liefert, statt weiterzuleiten, ist jeder erste Besuch eine Klartext-Anfrage. Leiten Sie alles HTTP per 301/308 auf HTTPS um und erzwingen Sie es dann mit HSTS, damit der Browser nie wieder HTTP versucht (siehe Fehler Nr. 1 in der Sicherheits-Header-Anleitung).

Zu weit gespannte Wildcard-Zertifikate

Ein *.example.com-Zertifikat über unverbundene Dienste bedeutet, dass ein gestohlener privater Schlüssel sie alle kompromittiert. Bequem, aber es vergrößert den Wirkungsradius. Begrenzen Sie den Geltungsbereich von Zertifikaten auf die Dienste, die sie wirklich teilen müssen.

Prüfen Sie es fortlaufend, nicht einmalig

Die TLS-Konfiguration driftet: eine neue Subdomain, ein Load-Balancer-Tausch, eine vergessene Erneuerung. Nehmen Sie eine TLS-Prüfung in denselben Rhythmus auf wie bei Headern — So lesen Sie einen Website-Sicherheitsbericht behandelt, wie Sie diese Befunde in einen Wochenplan verwandeln, und die Preisseite zeigt die Scan-Limits, um es geplant zu halten.