Worum geht’s
Jede https://-Verbindung beginnt mit einem TLS-Handshake. Wenn ein Browser „Verbindung
nicht sicher” meldet, ein Dienst nach einem Update nicht mehr erreichbar ist oder ein
Audit veraltete Cipher bemängelt, muss der Second-Level den Handshake, die Versionen und
die Cipher-Suite-Auswahl verstehen — und mit einem TLS-Check belegen können.
Konzept
TLS (Transport Layer Security) verschlüsselt den Transport und stellt sicher, dass man mit dem echten Server spricht. Der Handshake verhandelt vor dem Datenverkehr Version, Verfahren und Schlüssel:
- ClientHello — der Client nennt unterstützte Versionen, Cipher-Suites und sendet einen ephemeren Key-Share.
- ServerHello — der Server wählt Version + Cipher und schickt seinen Key-Share.
- Certificate / CertificateVerify — der Server beweist seine Identität per Zertifikat und Signatur.
- Finished — beide bestätigen verschlüsselt; ab jetzt fließen Anwendungsdaten.
Versionen: TLS 1.2 ist noch verbreitet, TLS 1.3 ist Standard — schlanker (1 Round-Trip), nur noch sichere Cipher, immer Perfect Forward Secrecy (PFS). TLS 1.0/1.1 und SSL sind abgeschaltet.
Cipher-Suite — das Bündel der eingesetzten Verfahren. Beispiel TLS 1.2:
ECDHE-RSA-AES128-GCM-SHA256 = Schlüsselaustausch (ECDHE → PFS) + Authentifizierung (RSA) +
Verschlüsselung (AES-128-GCM) + MAC/Hash (SHA-256). In TLS 1.3 ist die Suite verkürzt, da
Schlüsselaustausch und Auth fest ephemeral sind.
HSTS (HTTP Strict Transport Security) — ein Response-Header, der dem Browser sagt:
„Sprich mit dieser Domain ab jetzt nur über HTTPS.” Das verhindert SSL-Stripping und
versehentliche http://-Zugriffe.
Klick dich durch die Schritte: Beachte, dass die Identität (Certificate) erst nach der Versions- und Cipher-Wahl kommt — und alles ab dem Server-Finished verschlüsselt ist.
Beispiel-Fall
Aufgabe: Ein Audit verlangt: „Nur TLS 1.2+, PFS, HSTS aktiv.” Wie prüfst du example.com?
- TLS-Check ausführen → ausgegebene Versionen lesen. TLS 1.0/1.1 müssen abgelehnt werden, TLS 1.2 und/oder 1.3 akzeptiert.
- Cipher-Suite prüfen: Beginnt sie mit
ECDHE(oder ist TLS 1.3), liegt PFS vor — der Sitzungsschlüssel ist ephemeral, ein später kompromittierter Server-Key entschlüsselt alte Mitschnitte nicht. - HSTS prüfen: Ist der
Strict-Transport-Security-Header gesetzt (mitmax-age)? Ein langermax-ageund idealerweiseincludeSubDomainserfüllen die Vorgabe. - Verdikt: Erst wenn alle drei Punkte stimmen, ist die Vorgabe erfüllt — sonst Konfiguration am Webserver anpassen (alte Protokolle deaktivieren, HSTS setzen).
Anwenden
Vergleiche das Ergebnis mit den Audit-Kriterien aus dem Beispiel-Fall.
- Prüfe eine bekannte Domain und lies die akzeptierten TLS-Versionen ab.
- Schau in die ausgehandelte Cipher-Suite: Beginnt sie mit ECDHE (PFS)?
- Prüfe, ob der HSTS-Header gesetzt ist und wie lang max-age läuft.
Selbsttest
Praxis-Challenge
Wähle eine Domain und prüfe sie gegen die Audit-Vorgabe „TLS 1.2+, PFS, HSTS”. Notiere für jeden der drei Punkte das konkrete Ergebnis (Version, Cipher-Suite-Prefix, HSTS-max-age) und fälle ein begründetes Verdikt: erfüllt oder nicht — und falls nicht, welche Stellschraube fehlt.