Was HTTPS zu HTTP hinzufuegt

HTTP ist Klartext. Alles, was du in ein Formular tippst, jedes Session-Cookie und jedes API-Token reist als lesbare Bytes, und jedes Geraet auf dem Weg kann sie nicht nur lesen, sondern auch veraendern, ohne dass eine Seite es merkt. HTTPS ist dasselbe HTTP, nur innerhalb von TLS. Interessant ist dabei nicht die Verschluesselung, sondern dass sich beide Seiten auf einen geheimen Schluessel einigen koennen, waehrend ein Angreifer jede einzelne Nachricht der Verhandlung hoert.

Der Handshake ist diese Verhandlung, und er laeuft vor jeder Anfrage. Der Client oeffnet eine TCP-Verbindung und sendet dann ein ClientHello mit einer Zufallszahl, der Liste unterstuetzter Verfahren und seinem oeffentlichen Schluesselanteil. Der Server antwortet mit seiner eigenen Zufallszahl, dem gewaehlten Verfahren und seinem Schluesselanteil. Danach leiten beide Seiten dieselben Sitzungsschluessel ab, aus dem eigenen geheimen Wert und dem oeffentlichen der Gegenseite, und niemand, der das Gespraech mithoert, kann diese Rechnung wiederholen. Am Ende senden beide eine Finished-Nachricht, einen Hash ueber alles bisher Gesagte, sodass jede Aenderung waehrend des Handshakes die Pruefung sofort bricht.

Ein Zertifikat ist eine signierte Aussage, die einen oeffentlichen Schluessel an einen Hostnamen bindet. Darin stehen der Name, der oeffentliche Schluessel, ein Gueltigkeitszeitraum und eine Signatur einer Zertifizierungsstelle. Genau diese Signatur macht den Schluessel vertrauenswuerdig — der Schluessel allein beweist nichts. Wer jeden angebotenen Schluessel akzeptiert, bekommt vom Angreifer einfach dessen eigenen.

Chain
  1  leaf        CN=example.org
                 SAN: example.org, www.example.org
                 valid 2026-01-01 .. 2026-04-01
  2  intern     CN=R3 Intermediate CA
  3  root        CN=ISRG Root X1  (already on the device)

Validation
  signature of 1  checked with public key of 2    ok
  signature of 2  checked with public key of 3    ok
  signature of 3  checked with public key on device  ok
  name in SAN matches the host that was requested   ok
  current time inside the validity window           okEine Zertifikatskette und die fuenf Pruefungen, die ein Client durchfuehrt.

Die Kette ist der Grund, warum wenige Wurzeln fuer das ganze Netz reichen. Eine Wurzelinstanz signiert eine Zwischenstelle, die Zwischenstelle signiert das Zertifikat, das du erhaeltst, und dein Geraet muss nur der Wurzel bereits vertrauen — Wurzelzertifikate werden mit Betriebssystem und Browser ausgeliefert. Die Pruefung laeuft die Kette nach oben: Signatur des Endzertifikats mit dem Schluessel der Zwischenstelle pruefen, Zwischenstelle mit der Wurzel pruefen, pruefen dass die Wurzel vertrauenswuerdig ist, dann vergleichen, ob der Name im Zertifikat zum angefragten Host passt und ob das heutige Datum im Gueltigkeitszeitraum liegt. Jeder einzelne Fehlschlag beendet die Verbindung.

Ein Angreifer auf dem Weg, der kein gueltiges Zertifikat vorlegen kann, hat ein echtes Problem. Er kann Pakete verwerfen oder verzoegern, er kann sich als Adresse ausgeben, aber er kann die verschluesselten Bytes nicht lesen und den Handshake nicht faelschen, solange ihm kein Zertifikat zur Verfuegung steht, das dein Client akzeptiert. Ein veraendertes verschluesseltes Byte kippt kein Bit im Klartext — es scheitert die Authentifizierung, und die Verbindung endet. Deshalb ist es keine gute Idee, eine Zertifikatswarnung wegzuklicken: Entweder ist die Warnung ein echter Konfigurationsfehler, oder du hast gerade deine Sitzung dem uebergeben, der sie verursacht hat.

$ curl -v https://example.org
*  SSL certificate problem: self-signed certificate in certificate chain
*  Closing connection

$ curl -vk https://example.org
*  Server certificate: CN=mitm-proxy.local
*  subjectAltName does not match example.org
<  HTTP/1.1 200 OKDieselbe Anfrage mit und ohne Zertifikatspruefung.

Forward Secrecy beantwortet eine konkrete Frage: Was passiert mit Verkehr, der vor Jahren mitgeschnitten wurde, wenn heute der private Schluessel des Servers leckt? Im klassischen Verfahren wurde der Sitzungsschluessel mit dem oeffentlichen Schluessel des Servers verschluesselt, also genuegen aufgezeichneter Handshake und geleckter Schluessel fuer alles. Bei ephemerem Diffie-Hellman wird der Schluesselanteil fuer genau diese eine Verbindung erzeugt und danach verworfen, sodass ein spaeterer Schluesselverlust gegen alten Verkehr nutzlos ist. Gegen einen aktiven Angreifer hilft es nicht, und gegen den Diebstahl des Sitzungsschluessels selbst auch nicht. Es aendert den Wert eines gestohlenen Schluessels: statt der ganzen Geschichte eine einzige Sitzung.