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

Sie haben ein Zertifikat hinzugefügt, der Browser zeigt ein Schloss, und Sie machen weiter. Dann scheitert eines Tages ein API-Client mit SSL_ERROR_RX_RECORD_TOO_LONG, eine mobile App lehnt Ihre Kette ab, oder nach dem Aktivieren von HSTS erscheint eine Weiterleitungsschleife. Plötzlich fühlt sich HTTPS wie eine Blackbox an.

Dieser Artikel öffnet diese Box. Wir gehen durch, was während eines TLS-Handshakes tatsächlich passiert, warum Zertifikate existieren, wo symmetrische und asymmetrische Verschlüsselung jeweils hingehören und wie Sie die Fehler debuggen, die Ihnen in der Produktion realistisch begegnen werden.

Was HTTPS tatsächlich ist

HTTPS ist kein separates Protokoll. Es ist einfaches HTTP, das über eine TLS-verschlüsselte Verbindung gesendet wird. Das URL-Schema ändert sich, der Standardport wechselt von 80 auf 443, und alles andere – Methoden, Header, Statuscodes, Cookies – verhält sich gleich.

TLS bietet Ihnen drei Garantien zusätzlich zu TCP:

• Vertraulichkeit – Zwischenstellen können den Datenverkehr nicht lesen.
• Integrität – Manipulationen während der Übertragung werden erkannt.
• Authentifizierung – Der Client kann überprüfen, dass er mit dem Server spricht, dem die Domain gehört.

Die dritte Garantie wird oft unterschätzt. Verschlüsselung ohne Authentifizierung ist wertlos: Ein Angreifer, der den Datenverkehr abfangen kann, könnte einfach seinen eigenen Schlüssel präsentieren.

Der TLS-1.3-Handshake Schritt für Schritt

TLS 1.3 hat den Handshake im Vergleich zu TLS 1.2 drastisch vereinfacht. Hier ist der Ablauf zwischen einem Browser und einem Server:

1. ClientHello – Der Client sendet unterstützte TLS-Versionen, Cipher Suites, einen Zufallswert und einen Key Share für eine Diffie-Hellman-Gruppe (zum Beispiel X25519).
2. ServerHello – Der Server wählt eine Cipher Suite und sendet seinen eigenen Key Share. Beide Seiten können nun dasselbe gemeinsame Geheimnis ableiten.
3. Verschlüsselte Erweiterungen und Zertifikat – Der Server sendet seine Zertifikatskette, bereits verschlüsselt mit den abgeleiteten Schlüsseln.
4. Finished – Beide Seiten senden einen MAC über das Handshake-Transkript, um zu beweisen, dass nichts manipuliert wurde.
5. Anwendungsdaten – HTTP-Anfragen und -Antworten fließen über die etablierte Sitzung.

In TLS 1.3 kostet der vollständige Handshake einen Round Trip, und bei Resumption sind null Round Trips möglich. TLS 1.2 benötigte zwei Round Trips, bevor Anwendungsdaten fließen konnten.

Warum das Zertifikat erst nach der Schlüsselableitung gesendet wird

In TLS 1.3 ist das Zertifikat verschlüsselt. Das bedeutet, dass ein passiver Beobachter allein aus dem Zertifikat nicht einmal sehen kann, welche Domain der Client besucht, was die Informationslecks reduziert. Es bedeutet auch, dass Debugging-Tools, die ein Klartext-Zertifikat in den ersten Paketen erwarten, verwirrt wirken.

Symmetrische vs. asymmetrische Verschlüsselung

Ein verbreitetes Missverständnis ist, dass HTTPS alles mit dem öffentlichen Schlüssel des Servers verschlüsselt. Das tut es nicht. Asymmetrische Kryptografie ist langsam und größenbeschränkt; sie wird nur verwendet, um ein gemeinsames Geheimnis zu etablieren.

Der Diffie-Hellman-Schlüsselaustausch hat eine wertvolle Eigenschaft namens Forward Secrecy: Selbst wenn der private Schlüssel des Servers später leakt, können aufgezeichnete vergangene Sitzungen nicht entschlüsselt werden, weil die Sitzungsschlüssel nie aus diesem langfristigen Schlüssel abgeleitet wurden.

Was in einem Zertifikat steckt

Ein X.509-Zertifikat bindet einen öffentlichen Schlüssel an einen Domainnamen. Es enthält:

• Das Subjekt (Domain) und die Subject Alternative Names (SANs), die Browser tatsächlich prüfen.
• Den öffentlichen Schlüssel und seinen Algorithmus.
• Den Gültigkeitszeitraum.
• Den Aussteller und eine Signatur von diesem Aussteller.

Browser vertrauen einer festen Menge von Root-Zertifizierungsstellen. Ihr Server sendet ein Intermediate-Zertifikat, und der Browser baut eine Kette von Ihrem Leaf-Zertifikat bis zu einem vertrauenswürdigen Root. Wenn das Intermediate fehlt, funktionieren Desktop-Browser möglicherweise trotzdem, weil sie Intermediates cachen, während mobile Clients und Kommandozeilen-Tools scheitern. Dies ist der häufigste TLS-Fehler in der Produktion.

Praktische Debugging-Schritte

Wenn HTTPS sich falsch verhält, arbeiten Sie von außen nach innen.

1. Prüfen Sie die Kette mit openssl s_client -connect example.com:443 -servername example.com -showcerts. Bestätigen Sie, dass der Server die vollständige Kette sendet, nicht nur das Leaf.
2. Prüfen Sie den Ablauf – abgelaufene Zertifikate führen zu harten Fehlern ohne Workaround.
3. Prüfen Sie den Hostnamen – die SAN-Liste muss den exakten Hostnamen enthalten, den der Client anfragt, einschließlich eines eventuellen www-Präfixes.
4. Prüfen Sie die Protokollversion – wenn ein Legacy-Client nur TLS 1.0 unterstützt und Ihr Server TLS 1.2+ erfordert, scheitert der Handshake vor HTTP.
5. Prüfen Sie Weiterleitungen – eine Weiterleitung von HTTPS zu HTTP und zurück erzeugt eine Schleife; beheben Sie das in der Serverkonfiguration, nicht im Anwendungscode.

# Zertifikatskette und ausgehandeltes Protokoll inspizieren
openssl s_client -connect example.com:443 \
  -servername example.com -showcerts < /dev/null 2>&1 | \
  openssl x509 -noout -subject -issuer -dates

# Eine bestimmte TLS-Version testen
openssl s_client -connect example.com:443 -tls1_2 < /dev/null

In Nginx sollte die Direktive ssl_certificate auf eine Datei zeigen, die das Leaf-Zertifikat gefolgt vom Intermediate in dieser Reihenfolge enthält. Werden sie in der falschen Reihenfolge zusammengefügt, entstehen Kettenfehler, die leicht übersehen werden.

HSTS und die Kosten eines Fehlers

HTTP Strict Transport Security weist Browser an, für eine Domain für einen bestimmten Zeitraum HTTPS zu verwenden. Es ist mächtig und unnachgiebig: Sobald ein Browser eine lange max-age gesehen hat, verweigert er einfaches HTTP, selbst wenn Sie HTTPS später auf dem Server deaktivieren.

Beginnen Sie mit einer kurzen max-age, verifizieren Sie, dass alles funktioniert, und erhöhen Sie sie dann. Fügen Sie includeSubDomains erst hinzu, nachdem jede Subdomain gültiges HTTPS ausliefert. Preloading ist praktisch permanent – fordern Sie es nur an, wenn Sie sicher sind.

Häufige Fehlkonfigurationen

• Mixed Content – eine HTTPS-Seite, die Skripte oder Bilder über HTTP lädt. Browser blockieren aktiven Mixed Content und warnen bei passivem Inhalt.
• Schwache Cipher Suites – CBC-Modus-Cipher und alte Protokollversionen bleiben für Kompatibilität aktiviert, die Sie nicht mehr benötigen.
• Fehlende OCSP- oder CRL-Behandlung – die Sperrprüfung ist in der Praxis unzuverlässig; kurzlebige Zertifikate sind die robustere Antwort.
• Lücken bei der Zertifikatsautomatisierung – die Erneuerung funktioniert, aber der Reload-Schritt fehlt, der den Server das neue Zertifikat aufnehmen lässt.

Behandeln Sie die Zertifikatserneuerung als Deployment-Pipeline, nicht als Kalendererinnerung. Wenn die Erneuerung einen Menschen erfordert, wird sie irgendwann zum ungünstigsten Zeitpunkt fehlschlagen.

FAQ

Verschlüsselt HTTPS den Domainnamen, den ich besuche?

Die Domain erscheint in der TLS-SNI-Erweiterung und ist im Netzwerk normalerweise sichtbar. Der Pfad und die Query-String sind verschlüsselt, aber ein Netzwerkbeobachter kann in der Regel sehen, mit welchem Host Sie sich verbunden haben.

Warum funktioniert meine Website im Browser, aber nicht in curl oder einer mobilen App?

Fast immer ein fehlendes Intermediate-Zertifikat. Browser cachen oft Intermediates von früheren Besuchen, während curl und viele mobile HTTP-Stacks erfordern, dass der Server die vollständige Kette sendet.

Ist TLS 1.3 immer besser als TLS 1.2?

Für moderne Clients ja – weniger Round Trips, eine kleinere Cipher-Suite-Menge und Forward Secrecy standardmäßig. Lassen Sie TLS 1.2 nur aktiviert, wenn Sie noch Clients bedienen, die 1.3 nicht aushandeln können.

Wenn Sie Logs von den Servern inspizieren müssen, die TLS terminieren, hilft ein kurzer Durchlauf durch den Nginx-Log-Analyzer, Handshake-Fehler, Weiterleitungsschleifen und ungewöhnliches Client-Verhalten zu erkennen, bevor daraus Ausfälle werden.