So funktionieren HTTPS und TLS wirklich: Handshake erklärt

Sie haben https:// vor eine URL getippt, das Schloss gesehen und sind weitergegangen. Aber wenn um 2 Uhr morgens ein Zertifikat abläuft, eine Mixed-Content-Warnung Ihre Checkout-Seite lahmlegt oder ein Kunde fragt, warum sein API-Aufruf mit einem TLS-Fehler fehlschlägt, ist „das Schloss bedeutet, es ist sicher“ keine hilfreiche Antwort mehr. Dieser Artikel erklärt, was bei einer HTTPS-Verbindung tatsächlich auf der Leitung passiert und wie Sie sie ohne Rätselraten konfigurieren.

Was HTTPS zu HTTP hinzufügt

HTTPS ist reines HTTP, das in einer TLS-Sitzung (Transport Layer Security) übertragen wird. TLS bietet drei konkrete Garantien:

• Vertraulichkeit — der Datenverkehr wird verschlüsselt, sodass Zwischenstationen ihn nicht lesen können.
• Integrität — Manipulationen auf dem Transportweg werden erkannt und die Verbindung schlägt fehl.
• Authentifizierung — der Server beweist, dass er den privaten Schlüssel für das vorgelegte Zertifikat kontrolliert.

Beachten Sie, was nicht auf dieser Liste steht: HTTPS sagt nichts darüber aus, ob der Server vertrauenswürdig ist, ob die Anwendung Schwachstellen hat oder ob die Daten im Ruhezustand sicher sind. Es schützt die Leitung, nicht die Endpunkte.

Der TLS-Handshake Schritt für Schritt

Der Handshake ist die Aushandlung, die stattfindet, bevor HTTP-Bytes fließen. In TLS 1.3 dauert er einen einzigen Roundtrip; TLS 1.2 benötigt zwei. Hier ist der TLS-1.3-Ablauf in einfachen Worten:

1. ClientHello — der Client sendet unterstützte TLS-Versionen, eine Liste von Cipher Suites, eine zufällige Nonce und einen Key Share für einen Diffie-Hellman-Schlüsselaustausch (typischerweise X25519).
2. ServerHello — der Server wählt eine Version und Cipher Suite, sendet seinen eigenen Key Share und seine Zertifikatskette sowie eine Signatur über das Handshake-Transkript.
3. Schlüsselableitung — beide Seiten berechnen das gemeinsame Geheimnis aus dem Diffie-Hellman-Austausch. Ephemere Schlüssel bedeuten, dass der Sitzungsschlüssel einzigartig ist und Forward Secrecy gilt: Die spätere Kompromittierung des langfristigen Serverschlüssels entschlüsselt aufgezeichneten Datenverkehr nicht.
4. Finished — beide Seiten senden einen MAC über das Transkript. Wenn etwas verändert wurde, bricht der Handshake ab.
5. Anwendungsdaten — HTTP-Anfragen und -Antworten werden mit symmetrischen Schlüsseln verschlüsselt, die aus dem gemeinsamen Geheimnis abgeleitet wurden.

Das Zertifikat ist der Ort, an dem die Authentifizierung stattfindet. Der Server signiert den Handshake mit seinem privaten Schlüssel; der Client verifiziert diese Signatur mit dem öffentlichen Schlüssel im Zertifikat und überprüft dann das Zertifikat selbst gegen eine vertrauenswürdige Root-CA, wobei er Hostname, Gültigkeitsdaten und Sperrstatus prüft.

Symmetrisch vs. asymmetrisch: Warum beides verwendet wird

Asymmetrische Kryptographie (RSA oder ECDSA) ist langsam, löst aber das Schlüsselverteilungsproblem. Symmetrische Verfahren (AES-GCM, ChaCha20-Poly1305) sind schnell, erfordern aber einen gemeinsamen Schlüssel. TLS verwendet asymmetrische Kryptographie nur während des Handshakes, um einen symmetrischen Sitzungsschlüssel zu etablieren, und verschlüsselt dann Massendaten mit diesem Schlüssel. Deshalb ist eine moderne TLS-1.3-Verbindung schnell: ein Roundtrip, dann günstiges AES oder ChaCha20 für alles andere.

Cipher Suites und was wirklich zählt

Eine Cipher Suite ist ein benanntes Bündel von Algorithmen. In TLS 1.3 ist die Liste kurz und alle Optionen gelten als sicher; in TLS 1.2 müssen Sie sorgfältig wählen. Ein schneller Vergleich:

Praktische Konsequenz: Aktivieren Sie nur TLS 1.2 und 1.3, deaktivieren Sie TLS 1.0/1.1 und bevorzugen Sie ECDSA-Zertifikate für geringere Handshake-Kosten. Lassen Sie Ihren Server oder Reverse Proxy die Reihenfolge der Cipher Suites wählen; die meisten Standardeinstellungen in Software aus der Zeit um 2024 sind vernünftig.

So inspizieren Sie eine echte Verbindung

Sie müssen der Dokumentation nicht vertrauen — überprüfen Sie Ihre eigenen Endpunkte. openssl s_client zeigt die ausgehandelte Version, die Cipher Suite und die Zertifikatskette:

openssl s_client -connect example.com:443 -servername example.com -tls1_3 </dev/null

Achten Sie auf die Zeilen Protocol und Cipher und prüfen Sie dann die Ausgabe der Zertifikatskette auf Ablaufdatum und SAN-Einträge. Wenn die Kette unvollständig ist, schlagen einige Clients fehl, während Browser erfolgreich sind — eine klassische Ursache für „es funktioniert in Chrome, aber nicht in curl“-Fehler.

Häufige HTTPS-Fehlkonfigurationen

• Fehlendes Zwischenzertifikat — der Server sendet nur sein Leaf-Zertifikat. Browser laden das Zwischenzertifikat möglicherweise nach, API-Clients jedoch oft nicht.
• Mixed Content — eine HTTPS-Seite lädt ein Skript oder Bild über HTTP; Browser blockieren oder stufen es herab. Prüfen Sie dies mit der Browser-Konsole.
• Kein HSTS — ohne Strict-Transport-Security kann eine erste Anfrage über HTTP abgefangen werden, bevor die Weiterleitung erfolgt.
• Schwache oder veraltete Protokollversionen — TLS 1.0 für einen Legacy-Client aktiviert zu lassen, schwächt stillschweigend jede Verbindung.
• Zertifikatsablauf — automatisieren Sie die Erneuerung; eine manuelle Kalendererinnerung ist keine Strategie.

Eine vernünftige Serverkonfiguration

Für Nginx sieht ein minimaler moderner Block so aus:

server {
    listen 443 ssl http2;
    server_name example.com;

    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers off;
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 1d;

    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
}

Die Datei fullchain.pem ist das, was das Problem des fehlenden Zwischenzertifikats verhindert. Behalten Sie die Weiterleitung von Port 80 in einem separaten Server-Block, damit HTTP für ACME-Challenges weiterhin funktioniert.

Was HTTPS nicht schützt

Sobald die Anfrage Ihren Server erreicht, ist TLS erledigt. Injection-Schwachstellen, fehlerhafte Zugriffskontrolle, preisgegebene Geheimnisse in Logs und fehlkonfiguriertes CORS liegen alle oberhalb der Transportschicht. Betrachten Sie TLS als Grundlage, nicht als Sicherheitsprogramm. Wenn Sie einen Vorfall debuggen, trennen Sie frühzeitig Transportprobleme (Handshake-Fehler, abgelaufene Zertifikate) von Anwendungsproblemen (500er, fehlerhafte Payloads) — sie haben völlig unterschiedliche Lösungen.

FAQ

Verschlüsselt HTTPS den URL-Pfad und den Query-String?

Ja. Bei HTTPS befindet sich die gesamte HTTP-Anfrage, einschließlich Pfad und Query-String, im verschlüsselten TLS-Record. Allerdings sind der Hostname (SNI) und die Ziel-IP während des Handshakes sichtbar, es sei denn, Encrypted Client Hello wird verwendet.

Ist TLS 1.3 immer schneller als TLS 1.2?

Normalerweise ja, weil es einen Roundtrip spart und 0-RTT-Resumption unterstützt. Bei Verbindungen mit hoher Latenz ist der Unterschied spürbar; in einem lokalen Netzwerk ist er gering. Der größere Gewinn ist, dass TLS 1.3 Legacy-Cipher-Optionen vollständig entfernt.

Brauche ich HSTS noch, wenn ich HTTP auf HTTPS weiterleite?

Ja. Eine Weiterleitung hilft erst, nachdem der Browser Ihren Server erreicht hat. HSTS weist den Browser an, HTTP für zukünftige Anfragen vollständig zu überspringen, und schließt so das Zeitfenster, in dem eine erste Anfrage abgefangen werden könnte.

Wenn Sie ein Deployment prüfen und schnell Zertifikatsdetails überprüfen oder einen aufgezeichneten Handshake dekodieren müssen, halten Sie einen terminalbasierten Workflow bereit — und wenn Sie die Ergebnisse für ein Team dokumentieren, ist der Markdown-Editor eine schnelle Möglichkeit, rohe openssl-Ausgaben in einen lesbaren Bericht zu verwandeln.