TLS, Zertifikate & PKI
Erstmal einfach — Was passiert beim Schloss-Symbol?
Wenn du eine HTTPS-Seite öffnest, läuft im Hintergrund ein kompletter Krypto-Kongress ab — in unter 100 Millisekunden. TLS (früher SSL) ist das Protokoll, das das orchestriert. Es kombiniert fast alles, was du auf dieser Seite lernst, zu einem funktionierenden Ganzen.
Der TLS-Handshake in 4 Schritten
- ClientHello: Dein Browser sagt „Hallo, ich kann TLS 1.3, kann diese Cipher-Suites, hier mein zufälliger Nonce".
- ServerHello + Zertifikat: Der Server antwortet „nehmen wir TLS 1.3 mit ECDHE+AES-GCM, hier ist mein Zertifikat, hier ein Beweis dass ich den passenden privaten Schlüssel habe".
- Schlüsseltausch: Beide leiten via ECDHE einen gemeinsamen geheimen Sitzungsschlüssel ab.
- Verschlüsselte Anwendung: Ab jetzt alles AES-GCM-verschlüsselt — HTTP-Requests, Cookies, Inhalte.
Warum eigentlich? — Wozu das Zertifikat?
Schlüsseltausch allein löst nicht das wichtigste Problem: Wer ist eigentlich dieser Server? Diffie-Hellman erzeugt einen gemeinsamen Schlüssel — aber mit wem? Vielleicht mit einem Man-in-the-Middle, der zwei Tausche fährt und alles weiterleitet.
Ein Zertifikat ist eine signierte Aussage einer Zertifizierungsstelle: „Ich, Let's Encrypt, bestätige: dieser öffentliche Schlüssel gehört zu bank.de". Dein Browser vertraut Let's Encrypt (deren Root-Schlüssel ist im OS einprogrammiert) und damit dann auch indirekt bank.de.
Tiefer rein — PKI: die Vertrauenskette
PKI = Public Key Infrastructure. Aufbau:
- Root-CAs (z. B. DigiCert, Let's Encrypt-Root) — ihre Public Keys sind in Browsern und OS fest eingebaut. ~150 Stück weltweit.
- Intermediate-CAs — von der Root signiert, machen die eigentliche Arbeit. Werden separat gehalten, damit die Root offline bleiben kann.
- Server-Zertifikate — vom Intermediate für konkrete Domains ausgestellt.
Dein Browser prüft die ganze Kette: Server-Zert → signiert von Intermediate → signiert von Root → Root steht in der Liste. Wenn irgendwo eine Signatur nicht stimmt, Zertifikat abgelaufen ist oder der Domain-Name nicht passt: Warnsymbol.
Häufiger Denkfehler — „Das grüne Schloss heißt sicher!“
Bedeutet nur: die Verbindung zu diesem Server ist verschlüsselt und authentifiziert. Nicht: dass der Server vertrauenswürdig ist. Phishing-Seiten haben heute fast immer gültige Zertifikate (Let's Encrypt gibt sie kostenlos für jede Domain aus). Das Schloss sagt „Du redest wirklich mit paypa1-secure.com" — es weiß nicht, dass das nicht PayPal ist.
Auch: EV-Zertifikate (früher mit grüner Firmenleiste) sind inzwischen aus den meisten Browsern verschwunden — der Mehrwert war zu gering.
Geschichte — SSL → TLS — eine bewegte Geschichte
- SSL 1.0 — 1994, Netscape, nie veröffentlicht (gebrochen vor Release).
- SSL 2.0 — 1995, Designfehler, schnell ersetzt.
- SSL 3.0 — 1996, POODLE-Angriff 2014 → tot.
- TLS 1.0/1.1 — 1999/2006, seit 2021 offiziell verboten.
- TLS 1.2 — 2008, immer noch verbreitet, ok bei richtiger Konfiguration.
- TLS 1.3 — 2018, kompletter Reset: nur noch moderne Cipher-Suites, schneller Handshake (1-RTT statt 2-RTT), kein RSA-Schlüsseltausch mehr (nur ECDHE), Forward Secrecy verpflichtend.
Warum eigentlich? — Forward Secrecy — was und warum
Bei alten Handshakes wurde der Sitzungsschlüssel mit dem Server-RSA-Schlüssel transportiert. Falls jemand den Traffic aufzeichnete und Jahre später den Server-Schlüssel klaute, konnte er rückwirkend alles entschlüsseln.
Mit ephemerem Diffie-Hellman (ECDHE) werden für jede Sitzung frische temporäre Schlüssel benutzt. Nach der Sitzung weggeworfen. Selbst wenn der Server-Langzeit-Schlüssel später kompromittiert wird, bleiben alte Mitschnitte unentschlüsselbar.