Mehr als ein grünes Schloss
Jeder kennt das Schloss-Symbol im Browser — es bedeutet: die Verbindung ist verschlüsselt. Aber was passiert technisch dahinter? Wie stellen Browser und Server sicher, dass niemand mitlesen kann?
Dieser Artikel erklärt den kompletten TLS-Handshake — den Prozess, der jede HTTPS-Verbindung absichert. Von Zertifikaten über Schlüsselaustausch bis zu den Cipher Suites. Vorwissen aus unserem OSI-Modell-Artikel hilft, ist aber nicht Voraussetzung.
HTTPS = HTTP + TLS
HTTPS ist kein eigenes Protokoll — es ist normales HTTP, eingepackt in eine TLS-Verschlüsselungsschicht (Transport Layer Security). TLS ist der Nachfolger von SSL, wobei „SSL" umgangssprachlich noch oft verwendet wird.
Kryptographische Grundlagen
TLS nutzt drei Arten von Kryptographie in Kombination:
1. Asymmetrische Verschlüsselung (Public-Key)
Zwei Schlüssel: ein öffentlicher (zum Verschlüsseln) und ein privater (zum Entschlüsseln). Wird für den Schlüsselaustausch und Zertifikate verwendet. Algorithmen: RSA, ECDH, Ed25519.
2. Symmetrische Verschlüsselung
Ein gemeinsamer Schlüssel für Ver- und Entschlüsselung. Schnell — wird für die eigentliche Datenübertragung verwendet. Algorithmen: AES-128-GCM, AES-256-GCM, ChaCha20-Poly1305.
3. Hashing
Einweg-Funktion für Datenintegrität. Stellt sicher, dass Daten nicht manipuliert wurden. Algorithmen: SHA-256, SHA-384.
Der TLS 1.3 Handshake — Schritt für Schritt
TLS 1.3 braucht nur 1 Roundtrip (1-RTT) für den Verbindungsaufbau — TLS 1.2 brauchte noch 2. So läuft es ab:
Browser sendet: unterstützte TLS-Version, Cipher Suites, Key Shares (Diffie-Hellman-Parameter — schon beim ersten Paket!), Client Random.
Server wählt Cipher Suite, sendet eigenen Key Share. Beide Seiten berechnen den gemeinsamen Session Key. Server sendet sein Zertifikat (verschlüsselt!).
Server beweist mit digitaler Signatur, dass er den privaten Schlüssel zum Zertifikat besitzt. Sendet „Finished"-Nachricht.
Browser bestätigt. Handshake abgeschlossen. Alle weiteren Daten fließen symmetrisch verschlüsselt.
0-RTT Resumption: Bei erneutem Besuch kann TLS 1.3 sogar mit 0 Roundtrips starten — der Client sendet verschlüsselte Daten direkt mit dem Client Hello. Das funktioniert über einen Pre-Shared Key (PSK) aus der vorherigen Sitzung.
Zertifikate: Wer bürgt für den Server?
Ein TLS-Zertifikat ist der digitale Ausweis des Servers. Es wird von einer Certificate Authority (CA) ausgestellt und enthält:
Der Browser hat eine Liste vertrauenswürdiger CAs vorinstalliert. Er prüft die Zertifikatskette (Certificate Chain): Server-Zertifikat → Zwischen-CA → Root-CA. Stimmt alles: grünes Schloss. Mehr dazu: Warum SSL wichtig ist.
Cipher Suites: Die Rezeptur der Verschlüsselung
Eine Cipher Suite definiert, welche Algorithmen für eine TLS-Verbindung verwendet werden. In TLS 1.3 gibt es nur noch 5 empfohlene:
TLS 1.3 hat unsichere Algorithmen komplett entfernt (RC4, DES, MD5, SHA-1, statisches RSA). Der Schlüsselaustausch erfolgt immer über Ephemeral Diffie-Hellman — das garantiert Perfect Forward Secrecy.
Perfect Forward Secrecy (PFS)
PFS bedeutet: Selbst wenn der private Schlüssel des Servers in der Zukunft kompromittiert wird, kann vergangener verschlüsselter Traffic nicht nachträglich entschlüsselt werden.
Das funktioniert, weil jede Sitzung einen temporären (ephemeral) Schlüssel generiert, der nach der Sitzung vernichtet wird. In TLS 1.3 ist PFS Pflicht — in TLS 1.2 war es optional.
Debugging: TLS-Verbindung prüfen
Nützliche Tools für die Analyse:
Zeigt Zertifikat, Cipher Suite, TLS-Version
Verbose Output mit TLS-Details
Alle unterstützten Cipher Suites auflisten
Online: SSL Labs Server Test (ssllabs.com) gibt Ihrem Server eine Note von A+ bis F.
Sichere HTTPS-Konfiguration für Ihre Website
Bei Burwitz-IT Managed Hosting konfigurieren wir TLS 1.3 mit A+-Rating, automatischer Zertifikatserneuerung und HSTS — für jede gehostete Website. IT-Sicherheit ist bei uns inklusive. Jetzt informieren.