Zum Abschluss meiner kleinen Reihe zum Oberthema Kryptographie widmen wir uns der Funktionsweise von HTTPS in der einhundersechsundvierzigsten Episode des Anwendungsentwickler-Podcasts.

Inhalt

Wiederholung

Für die elektronische Signatur und die Verschlüsselung von Daten werden Paare aus öffentlichen und privaten Schlüsseln benötigt.

Um die Authentizität öffentlicher Schlüssel zu gewährleisten, werden Zertifikate verwendet, die von vertrauenswürdigen Zertifizierungsstellen ausgegeben werden.

Probleme

Wie können wir bei Millionen verschiedenen Websites sicherstellen, dass sie korrekte Schlüssel nutzen, ohne dass wir alle Websitebetreiber persönlich kennen müssen?

Wie kann bei den großen Datenmengen im Internet eine performante Verschlüsselung gewährleistet werden?

HTTPS

Um mit einem Webserver verschlüsselt kommunizieren zu können, benötigt der Webbrowser den öffentlichen Schlüssel des Webservers.

Diesen kann er einfach direkt vom Webserver selbst herunterladen. Aber wer garantiert ihm die Echtheit dieses Schlüssels? Vielleicht wurde der Server gehackt oder der private Schlüssel gestolen.

Deswegen liefert der Webserver nicht direkt den öffentlichen Schlüssel aus, sondern ein von einer CA ausgestelltes Zertifikat, das den öffentlichen Schlüssel des Webservers enthält, aber zusätzlich noch die Signatur der CA, die dessen Echtheit bestätigt.

Wenn dieses Zertifikat gültig ist (die Prüfung erfolgt gegen die "eingebauten" CAs im Browser), weiß der Browser sicher, dass er den korrekten Schlüssel erhalten hat und kann ihn für die Verschlüsselung nutzen.

Dabei prüft der Browser auch, ob das Zertifikat zur aktuellen Domain gehört. Der CN enthält bei HTTPS-Zertifikaten diese Domain.

Es gibt seit einiger Zeit auch eine kostenlose CA: Let's Encrypt. Damit kann sich jeder Webserverbetreiber gültige Zertifikate erzeugen, indem er technisch nachweist, dass die Domain und der Server wirklich ihm gehören.

Der Datenverkehr wird bei HTTPS symmetrisch verschlüsselt, da die Schlüssellängen hierbei deutlich kürzer sind, was deutliche Performancevorteile hat. Um diesen Schlüssel zwischen Browser und Webserver auszutauschen wird das obige asymmetrische Verfahren genutzt. Deswegen ist HTTPS ein hybrides Verfahren.

Technischer Ablauf

CA

CA generiert privaten und öffentlichen Schlüssel.

CA erstellt selbstsigniertes Root-Zertifikat: ihr eigener öffentlicher Schlüssel signiert mit ihrem privaten Schlüssel.

CA-Root-Zertifikat wird in Browser eingebaut.

Webserver

Webserver generiert privaten und öffentlichen Schlüssel.

Webserver lässt öffentlichen Schlüssel von CA mit ihrem privaten Schlüssel signieren.

Webserver installiert dieses Zertifikat und konfiguriert HTTPS.

Browser

Browser öffnet Website auf dem Webserver.

Webserver liefert sein Zertifikat aus.

Browser prüft das Zertifikat mit dem öffentlichem Schlüssel der CA aus seinem eingebautem Root-Zertifikat und erhält den öffentlichen Schlüssel des Webservers.

Browser generiert einen zufälligen temporären Sitzungsschlüssel und verschlüsselt ihn mit dem öffentlichen Schlüssel des Webservers.

Browser sendet den verschlüsselten Sitzungsschlüssel an den Webserver, der ihn mit seinem privaten Schlüssel entschlüsselt.

Nun kennen Browser und Webserver den Sitzungsschlüssel und können damit symmetrisch den Datenverkehr verschlüsseln.

Mögliche Probleme mit HTTPS-Zertifikaten

Das Zertifikat ist abgelaufen.

Das Zertifikat passt nicht zur Domain.

Das Zertifikat wurde von einer nicht vertrauenswürdigen CA ausgestellt.

Links

Permalink zu dieser Podcast-Episode

RSS-Feed des Podcasts

Hypertext Transfer Protocol Secure

Wie funktioniert https?

Einführung inOpenSSL und X.509-Zertifikate

Let's Encrypt

Certificate Signing Request