So funktioniert HTTPS — der TLS-Handshake erklärt

So funktioniert HTTPS — der TLS-Handshake erklärt

Die interaktive FlowJam-Zeichenfläche zu dieser Erklärung — jede Bahn, jede Zeile und jeder Pfeil oben gehört zu einem echten QueryChart-Diagramm, das Sie öffnen und bearbeiten können.

So lesen Sie diese Darstellung

• Lesen Sie die Spalte „TLS-Handshake“ von oben nach unten, danach die Spalte „Sichere Sitzung“: erst die Verhandlung, dann die Verschlüsselung.
• Die Bahn „Zertifizierungsstelle“ liegt nicht im Nachrichtenpfad — sie ist die Partei, auf deren Vertrauen sich der Browser stützt, um das Zertifikat des Servers zu beurteilen.
• Die Entscheidung „Zertifikat gültig und nicht abgelaufen?“ ist die einzige Verzweigung: Ein gültiges Zertifikat führt weiter zum Schlüsselaustausch, ein ungültiges endet bei der blockierenden Warnung.

Der Handshake

„Browser verbindet sich mit der HTTPS-Seite“ startet den Ablauf, und „Browser sendet ClientHello mit Cipher Suites“ nennt die Protokollversionen und Verschlüsselungsverfahren, die der Browser einsetzen kann. „Server antwortet mit Zertifikat und ServerHello“ wählt daraus aus und legt seine Identität vor — ein Zertifikat mit öffentlichem Schlüssel, ausgestellt auf die Domain. Dieses Zertifikat ist der gesamte Vertrauensanker von HTTPS.

Wer für den Server bürgt

„Browser prüft die Zertifikatssignatur gegen die CA“ steht in der Gruppe „Zertifizierungsstelle“, weil das Zertifikat von einer CA signiert ist und der Browser dem öffentlichen Schlüssel der CA vertraut. Die Entscheidung „Zertifikat gültig und nicht abgelaufen?“ prüft dann die drei tatsächlichen Punkte auf einmal: die Signatur, den Domainnamen im Zertifikat sowie Ablauf und Widerruf. Der Zweig „Nein“ endet bei „Browser blockiert die Verbindung mit einer Warnung“ — der Browser scheitert lieber geschlossen, als eine ungeprüfte Seite zu laden.

Die verschlüsselte Sitzung

Ist dem Zertifikat zu trauen, ist „Browser sendet ein Pre-Master-Secret, verschlüsselt mit dem öffentlichen Schlüssel des Servers“ die eine Nachricht, die nur der echte Server entschlüsseln kann. „Beide Seiten leiten denselben Sitzungsschlüssel ab“ erklärt daraufhin, dass die eigentlichen Daten überhaupt nicht mit den Schlüsseln des Zertifikats verschlüsselt werden — das Zertifikat schützt den Schlüsselaustausch, und ein frischer symmetrischer Schlüssel schützt das Gespräch. „Der Sitzungsschlüssel verschlüsselt HTTP-Nachrichten“ und „Browser und Server tauschen verschlüsselte Daten aus“ sind das, was HTTPS für den Rest des Seitenaufbaus ausmacht.

Wichtige Zusammenhänge und Erkenntnisse

• HTTPS ist HTTP innerhalb einer verschlüsselten TLS-Sitzung; die Verschlüsselung steht vor jeder HTTP-Nachricht.
• Das Vertrauen kommt von der Zertifizierungsstelle, nicht vom Server: Der Browser beurteilt das Zertifikat des Servers anhand einer CA, der er bereits vertraut.
• Die Schlüssel des Zertifikats werden einmal verwendet, um den Schlüsselaustausch zu schützen; ein frischer Sitzungsschlüssel verschlüsselt die eigentlichen Daten.
• Ein ungültiges oder nicht vertrauenswürdiges Zertifikat stoppt die Verbindung — HTTPS scheitert geschlossen, statt Daten unverschlüsselt zu senden.
• Alles, was HTTPS schützt, läuft über dasselbe paketvermittelte Netz, das die Darstellung zum Internet abbildet.

Wann Sie diese Darstellung nutzen

• Einem Team erklären, warum das Schloss erscheint und was eine Zertifikatswarnung tatsächlich bedeutet.
• Entwicklerinnen und Entwickler mit dem Handshake vertraut machen, bevor sie TLS-Probleme, abgelaufene Zertifikate oder Mixed-Content-Warnungen untersuchen.
• Das Vertrauensmodell vermitteln: wie die CA-Hierarchie und die Zertifikatsprüfung vor Identitätsmissbrauch schützen.

So funktioniert es

1. Nennen Sie Ihren tatsächlichen Zertifikatsaussteller

   Benennen Sie die Gruppe „Zertifizierungsstelle“ auf Ihren Anbieter um und vermerken Sie am Zertifikatskasten den Zertifikatstyp — DV, OV oder EV.

2. Ergänzen Sie die TLS-Version, die Sie betreiben

   Vermerken Sie am ClientHello-Schritt die Protokollversionen und Cipher Suites, die Sie tatsächlich aktivieren, damit das Diagramm Ihre Konfiguration zeigt und keine allgemeine.

3. Zeichnen Sie Ihre Fehlerzweige

   Ergänzen Sie die tatsächlichen Ausgänge, die Sie erlebt haben — ein abgelaufenes Zertifikat, ein nicht passender Hostname, ein widerrufenes Zertifikat — jeweils mit der Warnung oder Blockade, die daraus folgt.

4. Teilen Sie den Handshake so weit auf, wie Sie es brauchen

   Wenn Sie TLS 1.3 vermitteln, entfalten Sie den Schlüsselaustausch in seine echten Nachrichten (Key Share, Finished); nach dem Öffnen gehört die Zeichenfläche Ihnen.

Häufig gestellte Fragen

Was unterscheidet HTTP von HTTPS?

HTTPS ist HTTP innerhalb einer verschlüsselten TLS-Verbindung. Anfrage und Antwort sind genau dasselbe Protokoll; anders ist, dass Browser und Server vor jeder HTTP-Nachricht einen Handshake ausführen, der eine verschlüsselte Sitzung aufbaut. Alles Übertragene — URL, Header, Cookies, der Inhalt der Antwort — ist nur an den beiden Enden lesbar.

Was passiert während des TLS-Handshakes?

Der Browser sendet ein ClientHello mit den Protokollen und Cipher Suites, die er unterstützt; der Server antwortet mit seiner Wahl und seinem Zertifikat; der Browser prüft das Zertifikat gegen eine vertrauenswürdige Zertifizierungsstelle; und beide Seiten tauschen ein Geheimnis aus, aus dem sie denselben Sitzungsschlüssel ableiten. Danach fließen die HTTP-Nachrichten verschlüsselt. Die Darstellung fasst den Austausch zu diesen vier Schritten zusammen.

Warum braucht der Browser eine Zertifizierungsstelle?

Weil jeder Server behaupten könnte, eine beliebige Domain zu sein. Die Zertifizierungsstelle (CA) ist der Dritte, der das Zertifikat des Servers signiert, nachdem sie geprüft hat, dass die Domain dem Antragsteller gehört. Der Browser bringt die öffentlichen Schlüssel vertrauenswürdiger CAs mit und kann die Signatur deshalb selbst prüfen — das macht aus einer selbst behaupteten Identität eine verbürgte.

Was bedeutet eine Zertifikatswarnung?

Sie bedeutet, dass eine der Prüfungen in der Entscheidung „Zertifikat gültig und nicht abgelaufen?“ fehlgeschlagen ist — das Zertifikat ist abgelaufen, deckt eine andere Domain ab, wurde von einer nicht vertrauenswürdigen CA signiert oder wurde widerrufen. Der Browser blockiert die Verbindung, statt fortzufahren, weil die Identität der Seite nicht geprüft werden kann.

Diese Darstellung in QueryChart (FlowJam) bearbeiten

Öffnen Sie genau diese Zeichenfläche des TLS-Handshakes als eigenes Diagramm, vermerken Sie die Cipher Suites, die Sie unterstützen, und passen Sie sie an Ihren Zertifikatsaufbau an.

Diese Darstellung in QueryChart (FlowJam) bearbeiten