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

Podcast: Play in new window | Download (Duration: 39:14 — 18.6MB)

Abonnieren: Apple Podcasts | Spotify | RSS

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