HTTPS von Anfang bis Ende
Du tippst eine Adresse ein, du drückst Enter, und noch bevor du den Bildschirm siehst, steht links neben der Adresse schon ein Symbol, das sagt: Die Verbindung ist sicher. Dazwischen lag ein Gespräch. In diesen paar hundert Millisekunden haben dein Browser und der Server ein Geheimnis vereinbart, ein Beweisstück ausgetauscht und geprüft, und sind auf Verschlüsselung umgeschaltet. Dieses Kapitel zählt ab, was dabei passiert — und es kommt keine neue Mathematik dazu. Alles, was du brauchst, steht schon in den vorigen Kapiteln. Hier siehst du es zusammen am Werk.
Wörter, die du gleich brauchst
- HTTPS
- Das normale Web (HTTP) mit einer verschlüsselten Schicht darunter.
Diese Schicht heißt TLS.
https://in der Adressleiste bedeutet nichts anderes als: Hier steckt TLS drunter. - TLS
- Transport Layer Security. Die aktuelle Version ist TLS 1.3, und die steht in RFC 8446 vom August 2018. Ein RFC ist das öffentliche Dokument, in dem ein Internetstandard festgehalten wird; jeder kann es lesen.
- Handshake
- Wörtlich: das Händeschütteln. Die ersten paar Nachrichten, in denen Browser und Server abmachen, wie sie weiterreden. Danach beginnt der echte Verkehr.
- Rundreise
- Einmal hin und einmal zurück über das Netz. Auf Englisch round trip, abgekürzt RTT. Das ist die Einheit, in der Geschwindigkeit hier zählt: nicht in Rechenarbeit, sondern darin, wie oft du auf die andere Seite warten musst.
- Cipher Suite
- Das Päckchen Absprachen darüber, welche Algorithmen benutzt werden: welche Verschlüsselung, welche Hashfunktion. Browser und Server haben beide eine Liste davon, und sie suchen sich gemeinsam eine aus.
- SNI
- Server Name Indication. Das kleine Feld, in dem dein Browser sofort sagt, welche Seite er will. Auf einer IP-Adresse liegen oft Hunderte Seiten, der Server muss das also wissen, bevor er das richtige Zertifikat schicken kann.
- Man-in-the-Middle
- Jemand, der sich zwischen dich und den Server setzt und beiden vormacht, er sei die jeweils andere Seite. Er liest und verändert dann alles, ohne dass eine der beiden Seiten es merkt.
Der Handshake, Schritt für Schritt
- ClientHello. Dein Browser schickt als Erster eine Nachricht mit: welche TLS-Versionen er kann, welche Cipher Suites er kennt, welche Seite er will (das ist die SNI) — und gleich auch seine Hälfte des Schlüsselaustauschs. Er wartet also nicht, bis der Server gewählt hat; er rät, was der Server wahrscheinlich will, und schickt seine öffentliche Hälfte schon mal mit.
- ServerHello. Der Server wählt eine Version und eine Cipher Suite und schickt seine eigene Hälfte zurück. In diesem Moment können beide, jeder für sich, dieselbe Zahl ausrechnen: das gemeinsame Geheimnis. Das ist genau der Farbtrick aus Kapitel 5, meistens auf einer elliptischen Kurve. Es gibt jetzt einen Schlüssel, und der ist nie über die Leitung gegangen.
- Das Zertifikat und eine Signatur. Ab hier ist alles schon verschlüsselt — auch das, was jetzt kommt. Der Server schickt sein Zertifikat (Kapitel 7.2) und obendrauf eine Signatur über das ganze Gespräch bis hierher. Diese Signatur ist der Knackpunkt: Ein Zertifikat kann jeder kopieren, aber setzen kann so eine Signatur nur, wer den zugehörigen privaten Schlüssel hat. So weißt du, dass du mit dem echten Server redest und nicht mit einem Man-in-the-Middle.
- Dein Browser prüft. Drei Dinge, und alle drei müssen stimmen. Lässt sich die Signaturkette dieses Zertifikats bis zu einem Wurzelzertifikat verfolgen, dem er vertraut? Ist der Name im Zertifikat derselbe wie der, den du eingetippt hast? Sind wir innerhalb der Gültigkeitsdaten? Ein Nein, und du bekommst kein Schloss, sondern einen Warnbildschirm.
- Weiter symmetrisch. Von jetzt an geht alles — die Seite, die Bilder, dein Passwort, jeder Klick — symmetrisch verschlüsselt mit AES-GCM. Das ist Kapitel 4, und dass die schwere Mathematik nur für den Anfang gebraucht wird und der Rest schnell geht, ist Kapitel 7.3.
Welches Kapitel in welchem Schritt steckt
| Schritt | Was passiert | Das kanntest du schon aus |
|---|---|---|
| 1–2 | Beide schicken eine Hälfte, beide rechnen dasselbe Geheimnis aus | Kapitel 5, auf den Kurven von Kapitel 6.2 |
| 3 | Eine Signatur über das Gespräch, damit du weißt, wer da redet | Kapitel 7.1 |
| 3–4 | Das Zertifikat und die Kette bis zu einer vertrauten Wurzel | Kapitel 7.2 |
| 5 | Der ganze Rest des Besuchs, schnell verschlüsselt mit AES-GCM | Kapitel 4 |
| 1–5 | Langsame Mathematik für den Schlüssel, schnelle für die Daten | Kapitel 7.3 |
Eine Rundreise statt zwei
Dass der Browser seine Hälfte des Schlüsselaustauschs schon in seiner allerersten Nachricht mitschickt, klingt nach einem Detail. Es ist die größte Änderung von TLS 1.3 gegenüber seinem Vorgänger TLS 1.2. Dort lief es so: Erst fragte der Browser, was der Server kann, dann antwortete der Server, und erst danach begann der Schlüsselaustausch. Zweimal hin und her, bevor ein einziger Buchstabe Inhalt über die Leitung ging. TLS 1.3 schafft es mit einmal hin und her.
| TLS 1.2 | TLS 1.3 | |
|---|---|---|
| Rundreisen für den Handshake | 2 | 1 |
| Vorgehen | erst beraten, dann Schlüssel | raten und sofort Schlüssel; stimmt der Tipp nicht, wird erst dann beraten |
| Zertifikat des Servers | geht unverschlüsselt über die Leitung | geht verschlüsselt, denn es gibt schon einen Schlüssel |
Auf einer Verbindung, bei der eine Rundreise 50 Millisekunden kostet, spart das also 50 Millisekunden pro neuer Verbindung — und eine Seite holt ihre Bilder, Schriften und Skripte oft von einer Handvoll verschiedener Domains, jede mit einer eigenen Verbindung. So wurde die neuere Version gleichzeitig besser abgesichert und schneller.
Was das Schloss bedeutet und was nicht
| Bedeutet es | Bedeutet es nicht |
|---|---|
| Alles, was du schickst und bekommst, ist verschlüsselt. Wer im WLAN der Schule oder im Zug mithört, liest nichts mit. | Dass die Seite in Ordnung ist. Das Schloss sagt nichts darüber, wer dahintersteckt oder was die mit deinen Daten machen. |
| Der Name im Zertifikat ist derselbe Name, den du eingetippt hast, und eine Zertifizierungsstelle hat dafür unterschrieben. | Dass der Name, den du eingetippt hast, auch der Name ist, den du gemeint hast. Vertippst du dich um einen Buchstaben, dann stimmt das Zertifikat dieser anderen Seite einwandfrei. |
Das Zweite ist kein theoretisches Problem. Ein Zertifikat kostet heute nichts mehr und ist in Minuten besorgt — auch für jemanden, der eine Fälschung einer Login-Seite baut. Mehr als neun von zehn Phishing-Seiten haben ein gültiges Zertifikat und damit ein Schloss — 2019 waren es noch etwa sechs von zehn. Das Schloss beweist, dass niemand unterwegs mitliest — nicht, dass dem Ziel zu trauen ist.
Google hat 2021 untersucht, was Leute glaubten, was das Schloss bedeutet. 11 Prozent lagen richtig; der Rest las es als Gütesiegel. Deshalb ist das Schloss in Chrome seit Version 117 vom September 2023 durch ein neutrales Symbol mit zwei Schiebereglern ersetzt. Nicht, weil sich an der Sicherheit etwas geändert hätte, sondern weil das Symbol das Falsche versprach.
Mach es selbst, sofort. Klick auf das Symbol links neben der Webadresse hier oben — in Chrome und Edge die zwei Schieberegler, in Firefox noch ein Schloss-Symbol. Suchst du dich durch bis zu Verbindung ist sicher und dann zum Zertifikat, dann siehst du genau die Dinge aus Schritt 4: für welchen Namen es gilt, wer es ausgestellt hat, zwischen welchen zwei Daten es gültig ist, und die Kette darüber bis zur Wurzel. Das ist das Zertifikat der Seite, die du gerade liest.
Was ein Lauscher trotzdem sieht
Verschlüsselt heißt nicht unsichtbar. Wer den Verkehr in deinem Netz mitlesen kann — dein Internetanbieter, wer das WLAN verwaltet — weiß immer noch ein paar Dinge.
| Sieht er schon | Sieht er nicht |
|---|---|
| Welche Domain du besuchst. Sogar zweimal: in der DNS-Frage, mit der dein Browser die IP-Adresse nachschlägt, und in der SNI im ClientHello, die unverschlüsselt sein muss, weil der Server sonst nicht weiß, welches Zertifikat er schicken soll. | Welche Seite dieser Domain. Dass du auf einer Site warst, ja; dass du dort diesen Artikel gelesen hast, nein. |
| Wie viele Daten hin und her gehen, und wann. Aus einem Muster von Paketgrößen und Pausen lässt sich manchmal überraschend viel erraten. | Den Inhalt. Deine Suchanfrage, dein Passwort, deine Nachricht, die Seite selbst. Da kommt er nicht heran. |
An diesem ersten Leck wird gearbeitet. Encrypted Client Hello (ECH) verpackt das echte ClientHello — mit der echten SNI darin — verschlüsselt in eine harmlos aussehende Hülle. Den Schlüssel dafür holt sich dein Browser aus dem DNS. Chrome hat es seit Version 117 (September 2023) standardmäßig an, Firefox seit Version 119 (Oktober 2023), und seit März 2026 ist es ein offizieller Internetstandard: RFC 9849.
Halb zu also, nicht ganz. Es funktioniert nur, wenn die Seite selbst mitmacht und ihren Schlüssel im DNS veröffentlicht, und das tun längst nicht alle. Und deine DNS-Frage bleibt sichtbar, solange die nicht auch verschlüsselt läuft (DNS over HTTPS). Die IP-Adresse, zu der deine Verbindung geht, sieht er ohnehin: ohne Adresse kommt kein Paket an.
HSTS: komm nie mehr über http
Es gibt einen Moment, in dem es schiefgeht. Tippst du site.be
ohne https:// davor, dann probiert es dein Browser von jeher
zuerst über normales http — unverschlüsselt. Genau diese erste Frage
kann ein Man-in-the-Middle abfangen und auf seine eigene Kopie umleiten, und
dann gehört ihm der Rest deines Besuchs. Deshalb kann eine Seite in ihrer
Antwort eine Zeile mitschicken, die sagt: Merk dir, dass du zu mir nur
noch über https kommen darfst, mit einem Ablaufdatum dabei. Das heißt
HSTS, beschrieben in RFC 6797 vom November 2012. Dein Browser merkt es sich
und versucht es danach nicht einmal mehr über http — auch nicht, wenn
du es tippst, und auch nicht, wenn du auf „trotzdem weiter“ klicken willst.
Die Lücke bleibt nur bei diesem allerersten Besuch, und dafür führen Browser
eine eingebaute Liste von Domains, die schon immer https sind.
Das ist Mathematik: ein Protokoll beweisen statt ausprobieren
Ein Handshake ist keine Rechenaufgabe, sondern ein Gespräch: wer sagt was, in welcher Reihenfolge, und was darfst du daraus schließen. Die Frage „Kann ein Angreifer, indem er Nachrichten abfängt, wiederholt oder vertauscht, jemals mit einem Schlüssel enden, den er nicht haben dürfte?“ kannst du nicht durch Ausprobieren beantworten. Es gibt zu viele Reihenfolgen. Du musst es beweisen.
Genau das ist mit TLS 1.3 passiert, und das war eine Premiere: Der Entwurf wurde nachgerechnet, während er noch ein Entwurf war, nicht hinterher. Cas Cremers und vier Kolleginnen und Kollegen gossen Version 21 des Entwurfs in den Beweisassistenten Tamarin und ließen ihn die Angriffsmöglichkeiten durchgehen — die Arbeit erschien auf der CCS-Konferenz von 2017, knapp ein Jahr bevor es RFC 8446 im August 2018 gab. Frühere TLS-Versionen waren nicht so entstanden, und in denen hat man jahrelang immer neue Löcher gefunden.
Dieses Fach heißt formale Verifikation, und es sitzt auf der Grenze zwischen Mathematik und Informatik: Du schreibst ein Protokoll in Logik auf und lässt ein Programm alle möglichen Fälle durchgehen. Nicht „wir haben es getestet und es scheint zu funktionieren“, sondern „wir haben bewiesen, dass das andere nicht passieren kann“. Es wird auch für Zugsicherung, Chips und Flugzeugsoftware benutzt — überall dort, wo „wir haben es eine Weile probiert“ keine Antwort ist.