Kryptographie – Funktionsweise von HTTPS – Anwendungsentwickler-Podcast #146

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