TLS (Transport Layer Security)

Praxis-Nachtrag: Nutze TLS (Transport Layer Security) in einem Mini-Szenario. Eine kleine App soll einen Nutzer anmelden, eine Liste laden oder eine Bestellung speichern. Frage: An welcher Stelle taucht TLS (Transport Layer Security) auf, was würde ohne diesen Baustein fehlen, und welchen Fehler würdest du als Anfänger wahrscheinlich sehen? Diese Denkweise macht den Begriff sofort greifbarer als eine reine Definition.

Im Browser ist es das Schloss-Symbol. Auf dem Server (Nginx) brauchst du:

1. Einen Private Key (key.pem). Streng geheim!
2. Ein Zertifikat (cert.pem). Öffentlich. Unterschrieben von Let's Encrypt. Config:

ssl_certificate /etc/letsencrypt/live/domain/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/domain/privkey.pem;
ssl_protocols TLSv1.2 TLSv1.3;

Niemals TLS 1.0 oder 1.1 aktivieren!

1. Forward Secrecy (PFS)

Stell dir vor, der NSA zeichnet deinen Traffic heute auf (verschlüsselt). In 5 Jahren klauen sie den Private Key des Servers. Können sie die Aufzeichnung von heute entschlüsseln? Ohne PFS: Ja. (RSA Key Exchange). Mit PFS: Nein. Bei PFS (Diffie-Hellman Ephemeral) wird für jede Session ein Wegwerf-Schlüssel generiert. Der Server-Key dient nur zur Signatur ("Ich bin echt"), nicht zur Verschlüsselung. Darum ist RSA-Key-Exchange in TLS 1.3 verboten.

2. POODLE, BEAST, CRIME

TLS hat eine Geschichte von Sicherheitslücken. Meistens wegen "Downgrade Attacks". Hacker zwingt Server und Client, eine alte, kaputte Version (SSL 3.0) zu nutzen. Dann nutzt er bekannte Mathe-Schwächen (Padding Oracle), um Cookies zu erraten. Lösung: Server Härtung. Nur AES-GCM und CHACHA20 erlauben. Alle CBC-Ciphers verbieten.

3. TLS Termination vs Passthrough

Im Load Balancer (K8s Ingress):

• Termination: Load Balancer packt TLS aus, liest HTTP, schickt es unverschlüsselt an den Pod. (Schneller, einfacher, aber Traffic im Cluster ist klartext).
• Passthrough: Load Balancer reicht die Bytes durch. Pod muss entschlüsseln. (Sicherer Zero-Trust, aber Pod braucht Zertifikate).

1. Certificate Transparency (CT Logs)

Früher konnten böswillige (oder gehackte) Zertifizierungsstellen (CAs) heimlich ein Zertifikat für google.com ausstellen, um Leute auszuspionieren. Heute gibt es CT Logs. Jedes öffentlich gültige Zertifikat muss in ein öffentliches, unveränderbares Logbuch geschrieben werden. Moderne Browser verlangen einen kryptografischen Beweis (SCT), dass das Zertifikat geloggt wurde. Admins von Firmen wie Google können diese Logs überwachen und sehen sofort: "Hoppla, da hat gerade jemand ein Zertifikat für unsere Domain erstellt, das wir gar nicht bestellt haben!". Das macht betrügerische Zertifikate fast unmöglich.

2. OCSP Stapling (Performance vs. Privacy)

Woher weiß mein Browser, ob ein Zertifikat gestern gesperrt wurde (z.B. weil der Server gehackt wurde)? Früher fragte der Browser bei jedem Klick die CA: "Ist dieses Cert noch gültig?" (OCSP). Nachteil:

1. Die CA erfährt, welche Webseiten du besuchst (Privacy-Problem).
2. Die Webseite lädt langsamer. Beim OCSP Stapling fragt der Server selbst regelmäßig die CA und "tackert" die tagesaktuelle, signierte Gültigkeitsbestätigung direkt an den TLS-Handshake. Der Browser vertraut der Unterschrift der CA und muss selbst niemanden mehr anrufen.

3. Post-Quantum Cryptography (PQC)

Aktuelles TLS basiert auf Mathematik (Primzahlen, Elliptische Kurven), die von zukünftigen Quantencomputern in Sekunden gelöst werden könnte (Shor-Algorithmus). Google und Cloudflare testen bereits Hybrid-Krypto (z.B. X25519Kyber768). Dabei wird die Verbindung zweifach verschlüsselt: Einmal klassisch und einmal mit einem neuen, quantensicheren Algorithmus (Gitter-basierte Kryptografie). Selbst wenn die klassische Verschlüsselung später geknackt wird, schützt die PQC-Schicht die Daten. TLS 1.3 wurde so designt, dass solche neuen Algorithmen leicht nachgerüstet werden können.