Wie HTTPS und TLS wirklich funktionieren: Der Handshake erklärt

Sie tippen eine URL ein, drücken Enter, und ein Schloss erscheint. Aber was passiert eigentlich zwischen Ihrem Browser und dem Server, um diese Verbindung sicher zu machen? Viele Entwickler betrachten HTTPS als Blackbox – bis etwas schiefgeht, wie ein Zertifikatsfehler oder ein Performance-Problem. Dieser Artikel lüftet den Vorhang über TLS, dem Protokoll hinter HTTPS, und erklärt den Handshake in verständlichen Worten.

Was HTTPS wirklich ist

HTTPS ist einfach HTTP, das auf TLS (Transport Layer Security) aufsetzt. TLS bietet drei Garantien:

• Vertraulichkeit – Daten werden verschlüsselt, sodass Lauscher sie nicht lesen können.
• Integrität – Daten können während der Übertragung nicht unbemerkt verändert werden.
• Authentifizierung – Sie sprechen mit dem echten Server, nicht mit einem Betrüger.

Ohne TLS sendet HTTP alles im Klartext: Passwörter, Cookies und Formulardaten sind für jeden auf dem Netzwerkpfad sichtbar.

Der TLS-Handshake in einfachen Worten

Der Handshake ist die Aushandlung, die stattfindet, bevor Anwendungsdaten gesendet werden. Sein Ziel: sich auf Verschlüsselungsalgorithmen einigen, die Identität des Servers überprüfen und gemeinsame geheime Schlüssel etablieren. Hier ist der Ablauf für TLS 1.3, den modernen Standard:

1. Client Hello – der Browser sendet eine Liste unterstützter Cipher Suites, einen Zufallswert und seinen Key Share (für den Schlüsselaustausch).
2. Server Hello – der Server wählt eine Cipher Suite, sendet seinen eigenen Zufallswert und Key Share und stellt seine Zertifikatskette bereit.
3. Zertifikatsprüfung – der Browser prüft das Zertifikat gegen vertrauenswürdige Root-CAs, validiert den Domainnamen und prüft das Ablaufdatum.
4. Schlüsselableitung – beide Seiten berechnen dasselbe gemeinsame Geheimnis mittels Schlüsselaustausch (typischerweise ECDHE). Sitzungsschlüssel werden abgeleitet.
5. Finished – beide Seiten senden einen MAC über das Handshake-Transkript, um zu bestätigen, dass nichts manipuliert wurde.

Danach fließen verschlüsselte Anwendungsdaten. In TLS 1.3 dauert der Handshake einen Round Trip (1-RTT), und bei Wiederaufnahme kann 0-RTT erreicht werden.

TLS 1.2 vs. TLS 1.3

TLS 1.2 erforderte zwei Round Trips und unterstützte schwächere Algorithmen. TLS 1.3 entfernte veraltete Cipher, vereinfachte den Handshake und verschlüsselt mehr vom Handshake selbst. Bevorzugen Sie immer TLS 1.3; die meisten modernen Server und Browser unterstützen es.

Zertifikate: Der Vertrauensanker

Ein Zertifikat bindet einen öffentlichen Schlüssel an einen Domainnamen und wird von einer Zertifizierungsstelle (CA) signiert. Browser werden mit einem Speicher vertrauenswürdiger Root-CAs ausgeliefert. Während der Überprüfung baut der Browser eine Kette vom Serverzertifikat bis zu einer vertrauenswürdigen Root auf.

Häufige Zertifikatstypen:

• DV (Domain Validation) – beweist die Kontrolle über die Domain; schnell und kostenlos (z. B. Let's Encrypt).
• OV (Organization Validation) – enthält verifizierte Firmendetails.
• EV (Extended Validation) – strengere Identitätsprüfungen; zeigt in den meisten Browsern keine grüne Leiste mehr an.

Zertifikate laufen ab. Automatisieren Sie die Erneuerung mit ACME-Clients wie Certbot, um Ausfälle zu vermeiden.

Schlüsselaustausch und Perfect Forward Secrecy

Modernes TLS verwendet ephemeren Schlüsselaustausch (ECDHE). Jede Sitzung generiert ein neues Schlüsselpaar, sodass selbst wenn der private Schlüssel des Servers später kompromittiert wird, vergangene Sitzungen nicht entschlüsselt werden können. Diese Eigenschaft nennt man Forward Secrecy. Vermeiden Sie statischen RSA-Schlüsselaustausch, der diesen Schutz nicht bietet.

Häufige HTTPS-Fallstricke und wie man sie vermeidet

• Mixed Content – das Laden von HTTP-Ressourcen auf einer HTTPS-Seite löst Browserwarnungen aus. Verwenden Sie relative URLs oder aktualisieren Sie auf HTTPS.
• Abgelaufene Zertifikate – richten Sie Monitoring und automatische Erneuerung ein.
• Schwache Cipher Suites – deaktivieren Sie TLS 1.0/1.1 und RC4/3DES. Testen Sie mit einem Tool wie SSL Labs.
• Fehlendes HSTS – fügen Sie den Strict-Transport-Security-Header hinzu, um HTTPS zu erzwingen.

TLS-Probleme debuggen

Wenn ein Handshake fehlschlägt, verwenden Sie openssl s_client, um die Verbindung zu inspizieren:

openssl s_client -connect example.com:443 -servername example.com

Dies zeigt die Zertifikatskette, das ausgehandelte Protokoll und die Cipher. Bei browserspezifischen Fehlern prüfen Sie das Security-Panel in den DevTools.

FAQ

Ist HTTPS dasselbe wie TLS?

HTTPS ist HTTP über TLS. TLS ist das kryptografische Protokoll; HTTPS ist die sichere Version des HTTP-Anwendungsprotokolls.

Brauche ich ein separates Zertifikat für jede Subdomain?

Nicht unbedingt. Ein Wildcard-Zertifikat deckt alle Subdomains erster Ebene ab, und ein Multi-Domain-(SAN-)Zertifikat kann mehrere Namen auflisten.

Wie verbessert TLS 1.3 die Performance?

TLS 1.3 reduziert den Handshake auf einen Round Trip (und null bei Wiederaufnahme) und vereinfacht die Cipher-Aushandlung, was die Latenz senkt.

Bereit, die Sicherheit Ihrer eigenen Website zu überprüfen? Verwenden Sie unseren Nginx-Log-Analysator, um verdächtige TLS-Fehler und Handshake-Fehlschläge in Ihren Logs zu erkennen.