Jedes Mal, wenn ihr eine URL mit https:// aufruft, arbeitet im Hintergrund TLS. Es ist das Protokoll, das alle bisher gelernten Konzepte zusammenbringt: asymmetrischen Schlüsselaustausch, symmetrische Massenverschlüsselung und Zertifikate zur Authentifizierung. Wer TLS versteht, versteht HTTPS.

Nach diesem Block könnt ihr:

• erklären, was TLS leistet (Vertraulichkeit, Integrität, Authentizität) und wie es sich von HTTP unterscheidet
• TLS-Versionen einordnen und begründen, warum TLS 1.0/1.1 verboten sind
• den TLS-Handshake in seinen Grundzügen beschreiben
• eine Cipher Suite lesen und ihre Bestandteile benennen
• Perfect Forward Secrecy und HSTS erklären
• mit OpenSSL die TLS-Konfiguration eines Servers prüfen

Was ist TLS?

TLS (Transport Layer Security) ist das Protokoll hinter HTTPS. Es sorgt dafür, dass die Verbindung zwischen Browser und Webserver verschlüsselt und authentifiziert ist. TLS ist das praktische Zusammenspiel aller bisher gelernten Konzepte.

HTTP vs. HTTPS:

HTTP:   Port 80  – Klartext, kein Schutz
HTTPS:  Port 443 – HTTP über TLS, verschlüsselt und authentifiziert

TLS bietet drei Dinge:

• Vertraulichkeit: Niemand kann den Inhalt mitlesen (hybride Verschlüsselung)
• Integrität: Niemand kann den Inhalt unbemerkt verändern (Authentifizierungscodes)
• Authentizität: Der Server ist wirklich der, der er vorgibt zu sein (Zertifikate / asymmetrisch)

TLS-Versionen

TLS hat sich über die Jahre entwickelt. Ältere Versionen haben bekannte Schwachstellen und sind verboten. Das ist keine Empfehlung – es ist eine Pflicht: RFC 8996 hat TLS 1.0 und 1.1 2021 offiziell verboten. Wer heute noch einen Server betreibt, der TLS 1.0 akzeptiert, betreibt ein Sicherheitsproblem:

Was TLS 1.3 besser macht:

• Handshake braucht nur noch 1 Round-Trip statt 2 — schnellerer Verbindungsaufbau
• Alle schwachen Algorithmen entfernt — nur noch wenige, sichere Cipher Suites möglich
• Forward Secrecy ist Pflicht — nicht optional wie in TLS 1.2
• RSA Key Exchange und statische DH komplett entfernt

# TLS-Version einer Verbindung prüfen
openssl s_client -connect example.com:443 </dev/null 2>/dev/null | grep "Protocol"

# Explizit TLS 1.3 testen
openssl s_client -connect example.com:443 -tls1_3

# Prüfen ob TLS 1.0 noch erlaubt ist (sollte Fehler geben bei korrekter Konfiguration)
openssl s_client -connect example.com:443 -tls1

Probiert es selbst:

1. Prüft die TLS-Version einer bekannten Webseite: openssl s_client -connect google.com:443 </dev/null 2>/dev/null | grep "Protocol"
2. Testet, ob TLS 1.0 erlaubt ist: openssl s_client -connect google.com:443 -tls1 – was passiert?
3. Lasst euch das Zertifikat anzeigen: openssl s_client -connect google.com:443 </dev/null 2>/dev/null | openssl x509 -text -noout | head -20
4. Vergleicht die Ergebnisse mit einer anderen Webseite eurer Wahl – gibt es Unterschiede bei TLS-Version oder Cipher Suite?

TLS-Handshake (vereinfacht)

Client (Browser)                              Server
     │                                           │
     │──── ClientHello ─────────────────────────►│
     │     TLS-Version, unterstützte Cipher,     │
     │     zufällige Zahl (Client Random)        │
     │                                           │
     │◄─── ServerHello ──────────────────────────│
     │     Gewählte Cipher Suite,                │
     │     zufällige Zahl (Server Random)        │
     │                                           │
     │◄─── Certificate ──────────────────────────│
     │     Zertifikat des Servers                │
     │     (enthält Public Key + Signatur der CA)│
     │                                           │
     │  Browser prüft: Ist das Zertifikat gültig?│
     │  Ist es von einer vertrauenswürdigen CA?  │
     │  Stimmt der Domainname überein?           │
     │                                           │
     │──── Key Exchange ────────────────────────►│
     │     (abhängig von Cipher Suite:           │
     │      RSA: verschlüsselter Pre-Master-Key  │
     │      ECDHE: Diffie-Hellman-Parameter)     │
     │                                           │
     │  Beide Seiten berechnen unabhängig        │
     │  denselben Session-Key aus:               │
     │  Client Random + Server Random            │
     │   + Shared Secret                         │
     │◄────── Finished (verschlüsselt) ──────────│
     │──────► Finished (verschlüsselt) ─────────►│
     │                                           │
     │  Ab jetzt: alles symmetrisch verschlüsselt│
     │  mit dem ausgehandelten Session-Key       │

Cipher Suites

Eine Cipher Suite ist die vollständige Beschreibung, welche kryptografischen Algorithmen in einer TLS-Verbindung für welchen Zweck verwendet werden. Wenn ein TLS-Handshake fehlschlägt, weil „keine gemeinsame Cipher Suite” gefunden wurde, liegt das daran, dass Client und Server unterschiedliche Listen haben. In TLS 1.3 ist das kaum noch ein Problem – die Liste ist kurz und modern. In TLS 1.2 kann es ein Albtraum sein.

So liest sich ein Cipher-Suite-Name:

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
│    │      │        │       │
│    │      │        │       └── Hash-Algorithmus (für MAC/Integrität)
│    │      │        └────────── Verschlüsselungsalgorithmus + Modus
│    │      └─────────────────── Authentifizierung (Zertifikatstyp)
│    └────────────────────────── Schlüsselaustausch
└─────────────────────────────── Protokoll

TLS 1.3 vereinfacht das – es gibt nur noch wenige, sichere Cipher Suites:

• TLS_AES_256_GCM_SHA384
• TLS_CHACHA20_POLY1305_SHA256
• TLS_AES_128_GCM_SHA256

Perfect Forward Secrecy (PFS)

Problem ohne PFS: Wenn ein Angreifer den privaten Schlüssel des Servers später kompromittiert, kann er damit alle aufgezeichneten vergangenen Verbindungen entschlüsseln.

Lösung PFS: Bei jedem Verbindungsaufbau werden neue, ephemere (kurzlebige) Schlüssel generiert (ECDHE – Elliptic Curve Diffie-Hellman Ephemeral). Der Session-Key wird nie übertragen und nicht gespeichert. Selbst wenn der Private Key des Servers gestohlen wird – vergangene Sessions bleiben sicher.

Cipher Suites mit DHE oder ECDHE im Namen unterstützen PFS.

HSTS – HTTP Strict Transport Security

Problem: Ein Angreifer könnte versuchen, eine HTTPS-Verbindung auf HTTP downzugraden (SSL-Stripping), bevor der Browser überhaupt die sichere Verbindung aufbaut.

Lösung HSTS: Der Server teilt dem Browser per HTTP-Header mit: „Diese Domain ist immer nur per HTTPS erreichbar.” Der Browser speichert das und weigert sich danach, eine HTTP-Verbindung aufzubauen — auch wenn jemand manipulierend eingreift.

HTTP-Response-Header:
  Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

  max-age=31536000  → gilt für 1 Jahr
  includeSubDomains → gilt auch für alle Subdomains
  preload           → Domain wird in Browser-Preload-Liste aufgenommen

Mit preload wird die Domain in eine fest im Browser eingebaute Liste aufgenommen — dann wird niemals eine HTTP-Verbindung versucht, selbst beim allerersten Besuch.

Merke: HSTS schützt vor SSL-Stripping-Angriffen. Ohne HSTS kann ein Angreifer beim allerersten Seitenaufruf (noch vor dem HTTPS-Redirect) in die Verbindung eingreifen.

Zusammenfassung

• TLS ist das Protokoll hinter HTTPS – es vereint asymmetrischen Schlüsselaustausch, symmetrische Verschlüsselung und Zertifikatsvalidierung
• TLS 1.3 ist empfohlen (1 Round-Trip, nur sichere Cipher, PFS Pflicht); TLS 1.2 noch akzeptabel; TLS 1.0/1.1 sind verboten
• Eine Cipher Suite beschreibt das vollständige Algorithmen-Set einer TLS-Verbindung
• Perfect Forward Secrecy (ECDHE): Ephemere Session Keys schützen vergangene Verbindungen, selbst wenn der Server-Key kompromittiert wird
• HSTS verhindert SSL-Stripping – der Browser weigert sich, HTTP-Verbindungen zur Domain aufzubauen

Selbsttest

1. Ein Server nutzt die Cipher Suite TLS_RSA_WITH_AES_128_CBC_SHA. Nennt zwei Probleme dieser Konfiguration.
2. Erklärt in zwei Sätzen, warum TLS 1.3 schneller ist als TLS 1.2.
3. Was ist SSL-Stripping, und wie schützt HSTS dagegen?

Wie geht es weiter?

TLS sichert Webverbindungen – aber kein System ist unknackbar. Was passiert, wenn ein Angreifer nicht den Algorithmus bricht, sondern die Implementierung angreift? Block 09 zeigt die wichtigsten Angriffe auf Verschlüsselung – und warum Kryptografie nur so stark ist wie ihre schwächste Konfiguration.