HTTP Public Key Pinning
HTTP Public Key Pinning (HPKP) ist ein Mechanismus zum Absichern des HTTPS-Protokolls gegen Man-in-the-Middle-Angriffe mit gefälschten, jedoch von einer anerkannten Zertifizierungsstelle (certificate authority) signierten Zertifikaten. HPKP ermöglicht die Einschränkungen der für eine Domain akzeptierten Zertifikate auf Basis des trust-on-first-use-Prinzips. Eine Liste gültiger Zertifikate wird mittels des HTTP Header Public-Key-Pins vom Server mit einer beschränkten Gültigkeit definiert und vom Webbrowser des Nutzers gespeichert, um diese bei einem zukünftigen Zugriff zur Überprüfung des Zertifikates zu nutzen.
Die Liste gültiger Zertifikate kann dabei jedes Zertifikat der Schlüsselhierarchie enthalten. Es ist somit möglich, sowohl End-Zertifikate für die spezifische Domain als auch Zertifikate von Zertifizierungsstellen als gültig zu definieren. Durch letzteres wird jedes von dieser Zertifizierungsstelle signierte Zertifikat akzeptiert.[1] Dabei muss die Liste gültiger Zertifikate sowohl mindestens ein Zertifikat enthalten, das genutzt wird, als auch mindestens ein Zertifikat, das derzeit nicht in Nutzung ist. Letzteres dient als Backup-Zertifikat, um die Gefahr eines vollständigen Verlustes aller als gültig definierten Zertifikate zu reduzieren.[2]
Geschichte
[Bearbeiten | Quelltext bearbeiten]HTTP Public Key Pinning wurde von Google im November 2011 vorgeschlagen und ist als RFC 7469 standardisiert.[3]
Chrome unterstützt HPKP seit Oktober 2015 (Version 46),[4] hat es mit der Version 68 jedoch als „abgekündigt“ (deprecated) definiert und entfernte dessen Unterstützung mit der Version 72[5] wieder. Firefox unterstützte HPKP seit Januar 2015 (Version 35), entfernte die Unterstützung jedoch im Januar 2020 mit Version 72.[6] Safari und Edge unterstützten HPKP im Gegensatz zu Opera nicht.[7]
Im Oktober 2017 regte Chris Palmer, Mitautor des HPKP-Standards und Mitarbeiter bei Google Chrome, an, die Unterstützung des Standards im Chrome Browser ab Version 67, die für Mai 2018 erwartet wird, als veraltet zu markieren und vollständig zu entfernen, sobald Certificate Transparency im Chrome Browser für alle Zertifikate verpflichtend wird. Die Nutzung des Standards sei gering geblieben. Einen Grund hierfür sieht Palmer in der schwierigen Auswahl einer Liste gültiger Zertifikate, da der Website-Betreiber nicht über alle damit zusammenhängenden Aspekte die Kontrolle habe, sondern diese auch von den Herstellern der Betriebssysteme und Browser, sowie den Zertifizierungsstellen abhängig sei. Insbesondere besteht die Gefahr, durch HPKP eine Website unbenutzbar zu machen – auch für Websites, die dieses selbst gar nicht einsetzen.[8]
HPKP-Nachteile
[Bearbeiten | Quelltext bearbeiten]- Die Komplexität von HPKP überforderte viele Website-Betreiber – und verhinderte daher eine schnelle und fehlerfreie Einführung.
- Website-Betreiber machen ihre Website unbrauchbar, wenn sie alle Schlüssel verlieren. Nutzer können entscheiden, nur Schlüssel von End-Zertifikaten zu pinnen. Verliert jemand bei einem Hardware-Defekt zugleich den Schlüssel für das aktuelle Zertifikat und den Ersatzschlüssel, erhält er, solange der PIN gilt, für die Website kein gültiges Zertifikat.
- Wenn Nutzer nur die Schlüssel der Zertifizierungsstellen pinnen, erwarten sie, dass diese weiterhin Zertifikate ausstellen. Als Mitte 2016 auffiel, dass Wosign Regeln für Zertifizierungsstellen verletzte – und StartCom erwarb, wurden beide Zertifizierungsstellen aus vielen Browsern gelöscht. Wer für seine Website das Root-Zertifikat von StartCom und als Ersatz jenes von Wosign pinnte, bekam von beiden kein Zertifikat.
- RansomPKP als Key-Pinning-Schutzgeld-Erpressung: Ein Angreifer, der einen Webserver hackt, kann eine Website mit einem vom Angreifer ausgestellten Zertifikat und Schlüssel pinnen und den Schlüssel löschen. Er fordert vom Website-Betreiber Lösegeld für die Rückgabe des privaten Schlüssels.
Alternativen bei Apps
[Bearbeiten | Quelltext bearbeiten]Die Technik des TLS-Zertifikat-Pinning im Browser per HPKP ist gescheitert und wieder ausgebaut worden (vgl. Kapitel Geschichte), aber das TLS-Zertifikat-Pinning in einer App auf einen mobilen Betriebssystem wie bspw. Android oder iOS ist praktikabel, da im Notfall ein Update des Zertifikates über den Update-Mechanismus des App-Stores erfolgen kann und entsprechende Betriebssystemschnittstellen bereitgestellt werden.[9]
Weblinks
[Bearbeiten | Quelltext bearbeiten]- Public Key Pinning im Mozilla Development Network
- Key Pinning schützt vor bösartigen Zertifizierungsstellen. In: Golem.de, 14. Oktober 2015
Einzelnachweise
[Bearbeiten | Quelltext bearbeiten]- ↑ RFC: – Public Key Pinning Extension for HTTP. April 2015, Abschnitt 2.6: Validating Pinned Connections. (englisch).
- ↑ RFC: – Public Key Pinning Extension for HTTP. April 2015, Abschnitt 2.5: Noting Pins. (englisch). RFC: – Public Key Pinning Extension for HTTP. April 2015, Abschnitt 4.3: Backup Pins. (englisch).
- ↑ RFC: – Public Key Pinning Extension for HTTP. April 2015 (englisch).
- ↑ Emily Stark: Rolling out Public Key Pinning with HPKP Reporting. Abgerufen am 30. Oktober 2017.
- ↑ chromestatus.com
- ↑ Mozilla veröffentlicht Firefox 72. Abgerufen am 8. Januar 2020.
- ↑ HTTP Public Key Pinning (HPKP). Mozilla Developer Network (MDN); abgerufen am 30. Oktober 2017.
- ↑ Chris Palmer: Intent To Deprecate And Remove: Public Key Pinning. groups.google.com, 27. Oktober 2017. Vergleiche auch: Hanno Böck: Chrome will HTTP Public Key Pinning wieder aufgeben. Golem.de, 29. Oktober 2017.
- ↑ Andreas Kurtz: iOS: Certificate Pinning per Konfiguration. In: Heise online. 12. Februar 2021 (Geschichte HPKP, Android und iOS). Abgerufen am 1. März 2021.