Ein fehlerhaft konfiguriertes TLS-Zertifikat kann eine gesamte Verschlüsselungskette unwirksam machen — das grüne Schloss im Browser ist kein Garant für Sicherheit.
TLS-Handshake entmystifiziert — was in Millisekunden passiert
Der TLS 1.3 Handshake (RFC 8446) benötigt nur einen Roundtrip (1-RTT) statt zwei bei TLS 1.2 — eine Verbesserung, die allein für Websites mit globaler Nutzerbasis Millionen von Stunden Wartezeit pro Jahr einspart. Der Client sendet im ClientHello nicht nur die unterstützten Cipher Suites und Erweiterungen, sondern auch bereits Key Shares für die unterstützten Schlüsselaustauschgruppen (typischerweise x25519 und secp256r1). Der Server wählt eine Gruppe, antwortet mit seinem Key Share, dem Zertifikat und der Finished-Nachricht — alles verschlüsselt mit dem bereits berechneten Handshake-Schlüssel. Die Besonderheit von TLS 1.3: Ab dem ServerHello ist der gesamte restliche Handshake verschlüsselt — ein passiver Beobachter sieht weder das Serverzertifikat noch die gewählte Cipher Suite.
Das kontroverseste Feature von TLS 1.3 ist 0-RTT (Zero Round-Trip Time Resumption). Wenn Client und Server bereits eine vorherige Session hatten, kann der Client mit dem Pre-Shared Key (PSK) aus der vorherigen Session sofort verschlüsselte Daten senden — ohne auch nur eine Antwort des Servers abzuwarten. Das Problem: 0-RTT-Daten sind nicht gegen Replay-Angriffe geschützt. Ein Angreifer, der den 0-RTT-Teil des ClientHello aufzeichnet, kann ihn erneut an den Server senden, und der Server kann nicht zuverlässig unterscheiden, ob es sich um eine legitime neue Verbindung oder ein Replay handelt.
- Encrypted Client Hello (ECH): Die jüngste Erweiterung verschlüsselt auch den SNI (Server Name Indication) im ClientHello. Ohne ECH kann ein Netzwerk-Beobachter sehen, welche Website der Client aufruft (die Domain steht im Klartext im SNI-Feld), auch wenn der restliche Verkehr verschlüsselt ist. ECH verwendet einen öffentlichen Schlüssel, der per DNS (HTTPS-Record) abgerufen wird, um den SNI zu verschlüsseln. Cloudflare und Firefox unterstützen ECH seit 2023.
- TLS 1.2 Downgrade-Schutz: TLS 1.3 implementiert einen cleveren Downgrade-Schutzmechanismus: Wenn ein TLS-1.3-fähiger Server gezwungen wird, TLS 1.2 zu verwenden, setzt er die letzten 8 Bytes des ServerHello.Random auf den speziellen Wert
44 4F 57 4E 47 52 44 01(„DOWNGRD“+0x01). Ein TLS-1.3-fähiger Client erkennt diesen Marker und bricht die Verbindung ab. - Session Tickets vs. Session IDs: TLS 1.2 bietet zwei Resumption-Mechanismen. Session Tickets sind problematisch: Der Verschlüsselungsschlüssel (STEK — Session Ticket Encryption Key) wird selten rotiert. Wer den STEK kennt, kann allen vergangenen Traffic entschlüsseln — Perfect Forward Secrecy wird effektiv außer Kraft gesetzt. TLS 1.3 adressiert dies mit PSK-basierten Tickets.
- Certificate Compression (RFC 8879): Zertifikatsketten können 3–5 KB groß sein. RFC 8879 ermöglicht Brotli- oder Zstd-Komprimierung, was die Handshake-Größe um bis zu 60 % reduziert. Unterstützt von Chrome, Firefox und Nginx (seit 1.23.4).
Cipher Suites & Kryptographie — die richtige Auswahl treffen
TLS 1.3 hat die Cipher-Suite-Auswahl radikal vereinfacht: Es gibt nur noch fünf gültige Cipher Suites, und alle verwenden AEAD-Verschlüsselung (Authenticated Encryption with Associated Data). Die empfohlene Konfiguration ist TLS_AES_256_GCM_SHA384 und TLS_CHACHA20_POLY1305_SHA256. ChaCha20 ist besonders auf Geräten ohne AES-NI-Hardwarebeschleunigung schneller als AES-GCM. Der Schlüsselaustausch wird separat über Supported Groups ausgehandelt: x25519 (Curve25519) ist der de-facto-Standard.
Für Post-Quantum-Sicherheit haben Google und Cloudflare bereits den hybriden Schlüsselaustausch X25519Kyber768Draft00 implementiert, der klassisches x25519 mit dem post-quanten-sicheren ML-KEM (ehemals CRYSTALS-Kyber) kombiniert. Chrome und Firefox aktivieren dies seit 2024 standardmäßig.
- TLS 1.2 Cipher-Suite-Reihenfolge: Bevorzugen Sie ECDHE-ECDSA-AES256-GCM-SHA384 oder ECDHE-RSA-AES256-GCM-SHA384. Deaktivieren Sie:
RC4(gebrochen),3DES(Sweet32-Angriff),CBC-Modi (BEAST, Lucky13, POODLE),RSA key exchange(keine Forward Secrecy). Apache:SSLCipherSuite ECDHE+AESGCM:ECDHE+CHACHA20:!aNULL:!MD5:!DSS. - HSTS Preloading:
Strict-Transport-Security: max-age=63072000; includeSubDomains; preloadund Anmeldung bei hstspreload.org bewirkt, dass Browser Ihre Domain fest in eine Preload-Liste kompilieren. Achtung: Die Aufnahme ist schwer rückgängig zu machen — die Entfernung dauert Monate. - OCSP Stapling vs. OCSP Must-Staple: OCSP Stapling löst Latenz- und Privacy-Probleme: Der Webserver fragt die CA ab und heftet die signierte OCSP-Antwort an den TLS-Handshake. Apache:
SSLUseStapling On; SSLStaplingCache shmcb:/tmp/stapling(128000). OCSP Must-Staple (RFC 7633) verhindert, dass ein Angreifer mit einem gestohlenen Zertifikat den OCSP-Check blockiert. - Certificate Transparency (CT): Seit 2018 erfordern Chrome und Safari, dass jedes öffentliche TLS-Zertifikat in mindestens zwei unabhängigen CT-Logs registriert ist. Überwachen Sie Ihre Domains mit
crt.shoder Certspotter: Jedes neu ausgestellte Zertifikat wird sofort sichtbar.
PKI-Schwachstellen — wenn die Vertrauenskette bricht
Die gesamte PKI basiert auf dem Vertrauen in Certificate Authorities (CAs) — und dieses Vertrauen wurde in der Vergangenheit mehrfach gebrochen. Im Jahr 2011 wurde die niederländische CA DigiNotar kompromittiert, und der Angreifer stellte ein gültiges Wildcard-Zertifikat für *.google.com aus. Dieses Zertifikat wurde nachweislich in Iran eingesetzt, um den Gmail-Verkehr von 300.000 iranischen Nutzern abzufangen. DigiNotar wurde aus allen Browser-Trust-Stores entfernt und ging bankrott.
Die Verteidigung gegen kompromittierte CAs besteht aus mehreren Schichten: Certificate Transparency macht jedes ausgestellte Zertifikat öffentlich sichtbar. CAA-Records (RFC 8659) ermöglichen es Domäneninhabern, festzulegen, welche CAs Zertifikate ausstellen dürfen. DANE/TLSA (RFC 6698) bindet das Zertifikat direkt an einen DNSSEC-gesicherten DNS-Record.
- CAA-Records konfigurieren:
example.com. IN CAA 0 issue "letsencrypt.org"erlaubt nur Let’s Encrypt. Zusätzlich:example.com. IN CAA 0 issuewild ";"verhindert Wildcard-Zertifikate.example.com. IN CAA 0 iodef "mailto:[email protected]"sendet Benachrichtigungen bei Policy-Verstößen. Wichtig: CAA wird von allen öffentlichen CAs seit September 2017 geprüft. - Let’s Encrypt Rate Limits: Maximal 50 Zertifikate pro registrierter Domain pro Woche. Bei automatisierter Zertifikatsausstellung kann dieses Limit schnell erreicht werden. Tipp: Verwenden Sie die Staging-Umgebung (
--staging) zum Testen. - Key Compromise — was tun? Wenn Ihr privater Schlüssel kompromittiert wurde: 1) Widerrufen Sie das Zertifikat sofort. 2) Generieren Sie einen neuen Schlüssel. 3) Stellen Sie ein neues Zertifikat aus. 4) Prüfen Sie via CT-Logs, ob der Angreifer weitere Zertifikate ausgestellt hat. 5) Rotieren Sie alle TLS-Session-Tickets.
- Private CA für interne Dienste: Für interne Netzwerke ist eine eigene CA oft sinnvoller. Tools: step-ca (Smallstep, ACME-kompatibel), HashiCorp Vault PKI, ADCS. Wichtig: Verwenden Sie eine Offline Root CA und Online Intermediate CAs.
Sie benötigen Unterstützung?
TLS-Konfiguration erfordert Präzision. Wir analysieren Ihre Verschlüsselungseinstellungen mit SSL Labs, implementieren OCSP Stapling, konfigurieren CAA-Records und stellen sicher, dass Ihre Zertifikatskette lückenlos ist.
Security & Firewall ansehen →
