Original-URL des Artikels: https://www.golem.de/news/https-chrome-will-http-public-key-pinning-wieder-aufgeben-1710-130871.html    Veröffentlicht: 29.10.2017 12:19    Kurz-URL: https://glm.io/130871

HTTPS

Chrome will HTTP Public Key Pinning wieder aufgeben

Es bringt zwar Sicherheitsgewinne, aber auch einige Gefahren: HTTP Public Key Pinning (HPKP) ist ein kontroverses Feature in Browsern. Jetzt will Chrome es wieder abschaffen - und setzt stattdessen vor allem auf Certificate Transparency.

Key Pinning sollte einst das HTTPS-Ökosystem sicherer machen und eine Möglichkeit bieten, sich vor bösartigen oder gehackten Zertifizierungsstellen zu schützen. Doch der Standard HTTP Public Key Pinning (HPKP) dürfte wohl keine große Zukunft mehr vor sich haben. Chrome-Entwickler Chris Palmer kündigte in einer Mail an, dass das Feature wieder aus dem Google-Browser entfernt werden soll.

Die Idee von HPKP ist im Grunde relativ simpel: Eine Webseite kann über einen HTTP-Header festlegen, dass für einen gewissen Zeitraum nur bestimmte Schlüssel für diese Seite akzeptiert werden sollen. Dabei kann man sowohl Schlüssel von End-Zertifikaten als auch Schlüssel von Zertifizierungsstellen angeben. Es müssen zudem immer mindestens zwei Schlüssel angegeben werden, damit man im Zweifelsfall einen Ersatzschlüssel hat. Neben diesen dynamischen Pins, die Webseiten selber setzen können, hat Chrome auch eine Liste von statischen Pins, die bereits Teil des Browsercodes sind.

Webmaster können ihre Webseite unbrauchbar machen

Doch in der Praxis gestaltete sich HPKP als außerordentlich trickreich. Ein großes Problem: Webseitenbesitzer können damit ihre eigene Seite unbrauchbar machen - wenn sie alle Schlüssel verlieren. So könnte ein Nutzer sich beispielsweise entscheiden, nur die Schlüssel von End-Zertifikaten zu pinnen. Wenn jemand jetzt gleichzeitig den Schlüssel für das aktuelle Zertifikat und den Ersatzschlüssel verliert - beispielsweise durch einen Hardwareschaden - gibt es für den Zeitraum des Pins keine Möglichkeit mehr, für die Webseite ein gültiges Zertifikat zu erhalten.

Ein weiteres Problem: Wenn Nutzer sich entscheiden, nur die Schlüssel von Zertifizierungsstellen zu pinnen, verlassen sie sich darauf, dass diese weiter existieren und auch weiterhin Zertifikate ausstellen. Doch zuletzt kam es immer wieder vor, dass einzelne Zertifizierungsstellen aufgrund von Fehlverhalten aus den Browsern entfernt wurden.

Im Sommer 2016 wurde beispielsweise bekannt, dass Wosign in zahlreichen Fällen die Regeln für Zertifizierungsstellen verletzt hat, und gleichzeitig auch, dass Startcom von Wosign gekauft wurde. Beide Zertifizierungsstellen flogen daraufhin aus allen wichtigen Browsern raus. Ein Nutzer, der für seine Webseite das Root-Zertifikat von Startcom und als Ersatz das Root-Zertifikat von Wosign mit einem langem Zeitraum gepinnt hätte, wäre nun in einer ungünstigen Situation, da er von Startcom und Wosign keine gültigen Zertifikate mehr bekommen kann.

Gefahr von Key-Pinning-Ransomware

Ein weiteres Problem wurde auf der Def Con letztes Jahr unter dem Namen RansomPKP diskutiert. Die Idee dabei: Ein Angreifer, der einen Webserver hackt, könnte eine Webseite eine Zeit lang mit einem vom Angreifer ausgestellten Zertifikat und Key pinnen und anschließend den Schlüssel löschen. Anschließend fordert er vom Besitzer der Webseite ein Lösegeld für die Herausgabe des privaten Schlüssels. Bei RansomPKP handelt es sich bislang allerdings wohl nur um ein theoretisches Szenario. Tatsächliche derartige Angriffe sind bislang nicht bekannt geworden.

Es stellte sich zudem heraus, dass sehr viele Webseiten ungültige HPKP-Header verschickten, beispielsweise solche, die überhaupt keinen gültigen Schlüssel enthielten, oder syntaktisch inkorrekte Header. Ein deutlicher Hinweis darauf, dass die relativ einfach erscheinende Logik von vielen Webmastern nicht nachvollzogen werden konnte, oder dass diese die Header einfach aus irgendwelchen Anleitungen kopiert haben, ohne genau zu verstehen, was sie damit machen.

Der TLS-Experte Ivan Ristic hatte vor einem Jahr bereits die Frage gestellt, ob angesichts dieser vielen Probleme HPKP tot sei. Ristic versuchte sich zuletzt noch daran, verschiedene Vorschläge zu machen, wie man HPKP verbessern könnte.

Bei Chrome ist man jedoch inzwischen wohl zu der Überzeugung gelangt, dass HPKP generell nicht mehr sinnvoll ist. Die jetzigen Kritiker wie Chris Palmer und Ryan Sleevi sind übrigens selbst Mitautoren von HPKP. Auch die statischen Pins sollen langfristig aus Chrome verschwinden, allerdings erst dann, wenn Certificate Transparency für alle Zertifikate verpflichtend vorgeschrieben ist.

Insgesamt dürfte es damit für die Zukunft von HPKP düster aussehen. Safari und Edge unterstützen das Feature bisher sowieso nicht. Es bleiben noch Firefox und Opera, die HPKP unterstützen.

Certificate Transparency statt HPKP

Statt HPKP setzt man jetzt bei Chrome vor allem auf Certificate Transparency, um dem Fehlverhalten von Zertifizierungsstellen zu begegnen. Das Konzept von Certificate Transparency ist es, sämtliche HTTPS-Zertifikate in öffentlich einsehbaren und überprüfbaren Logs zu speichern. Certificate Transparency gibt Webseitenbesitzern die Möglichkeit, die Logs nach Zertifikaten für ihre Webseiten zu durchsuchen, die sie nicht selbst beantragt haben.

Die Hoffnung: Da Browser inzwischen immer härter gegen Fehlverhalten von Zertifizierungsstellen vorgehen, haben diese einen hohen Anreiz, fehlerhafte Zertifikatsausstellungen zu verhindern, da diese durch Certificate Transparency praktisch immer auffliegen dürften. Certificate Transparency kann anders als HPKP die Nutzung von fehlerhaft ausgestellten Zertifikaten nicht verhindern. Aber dafür kann man damit auch weniger falsch machen.  (hab)


Verwandte Artikel:
Browser-Fingerprinting: "Super-Cookies" verfolgen Nutzer auch im privaten Modus   
(07.01.2015, https://glm.io/111527 )
TLS-Zertifikate: Zertifizierungsstellen müssen CAA-Records prüfen   
(11.09.2017, https://glm.io/129981 )
20.000 Accounts erstellt: Hacker erschleichen sich Uber-Freifahrten   
(17.03.2016, https://glm.io/119841 )
LLVM 6.0: Clang bekommt Maßnahme gegen Spectre-Angriff   
(09.03.2018, https://glm.io/133241 )
ROBOT-Angriff: Arbeitsagentur nutzt uralte Cisco-Geräte   
(09.03.2018, https://glm.io/133258 )

© 1997–2019 Golem.de, https://www.golem.de/