Wachsende Kritik an Public Key Pinning für HTTPS

Insbesondere der ausgewiesene TLS-Experte Ivan Ristic geht hart mit HTTP Public Key Pinning ins Gericht. Wegen der hohen Einstiegshürden profitieren nur wenige von dessen Schutzfunktion. Dem gegenüber stünden jedoch viele Millionen unwissende Web-Seiten-Betreiber, die allein durch seine Existenz einem neuen Angriffsszenario ausgesetzt sind.

Der Standard für HTTP Public Key Pinning (HPKP, RFC 7469) soll das inhärente Vertrauensproblem der Transportverschlüsselung TLS lösen. In dessen Reinform kann eine unüberschaubare Zahl von Zertifizierungsstellen beliebige Zertifikate ausstellen, denen jeder Browser glaubt. So kann etwa die CA der chinesischen Regierung ein gültiges Zertifikat auf den Namen der Deutsche Bank ausstellen oder Symantec eines für Google. Letztere wurden dabei sogar schon mehrfach erwischt.

Mit HPKP kann ein Server dem Browser beim Besuch einer verschlüsselten Web-Seite mitteilen: "Wenn du beim nächsten Mal auf dieser Domain vorbeikommst, wird eines der folgenden Zertifikate zum Einsatz kommen. Merk dir das." Chrome und Firefox werden dann beim nächsten Besuch Zertifikate der chinesischen Regierungs-CA ablehnen – auch wenn sie formal gültig wären.

Ungeschützt bleibt allerdings der erste Besuch der Web-Site, bei dem der Server das richtige Zertifikat beziehungsweise den richtigen HPKP-Header liefern muss. Es handelt sich um Trust On First Use, kurz TOFU. Selbst wenn dieses TOFU-Konzept damit Lücken für Angriffe in Einzelfällen offen lässt, macht es doch unbemerkte Angriffe auf TLS-Verbindungen in größerer Zahl nahezu unmöglich.

Das Missbrauchs-Potential von HPKP

Die hauptsächliche Kritik richtet sich jedoch gar nicht gegen TOFU sondern gegen ein theoretisches Angriffsszenario, das ohne HPKP gar nicht möglich wäre: Erpressung von Web-Seiten-Betreibern, deren Besucher die Seiten wegen falscher HPKP-Pins nicht mehr aufrufen können.

Das Szenario beruht darauf, dass ein Angreifer sich in einen Web-Server hackt. Dort installiert er ein neues Zertifikat und konfiguriert den Server auf HPKP. Der Server liefert damit dann an alle Web-Seiten-Besucher seinen HPKP-Pin. Das lässt der Hacker so lange laufen, bis sich eine nennenswerte Zahl von Anwendern beziehungsweise deren Browser dieses Zertifikat gemerkt haben.

Wenn er anschließend das Zertifikat auf dem Server löscht, bekommen alle Anwender Fehlermeldungen. Der Web-Seiten-Betreiber kann sich nicht ohne Weiteres ein neues Zertifikat besorgen und einspielen. Denn obwohl damit alles seine Richtigkeit hat, werden die Browser ihm auf Grund des fixierten Pins für das Zertifikat des Hackers nicht glauben und eine Fehlermeldung präsentieren. Anders als die herkömmlichen Zertifikatswarnungen gibt es dabei auch kein "Ja, ja, mach ruhig". Nur der recht komplizierte Reset des Pinnings schaltet den Zugang wieder frei.

Das geht so lange, bis der HPKP-Eintrag abläuft. Bei Chrome etwa ist das erst nach spätestens 60 Tagen der Fall. Zwei Monate ohne Umsatz dürfte für viele Web-Seiten-Betreiber keine echte Option sein. Damit bleibt dann nur noch, dem Erpresser nachzugeben und ihm eine Summe X in Bitcoins in den Rachen zu werfen, um das via HPKP festgenagelte Zertifikat zu erhalten.

Solche HPKP-Erpressungen wurden zwar noch nicht beobachtet; sie sind aber prinzipiell durchaus möglich. Alle einfachen Schutzmaßnahmen wie regelmäßige Offsite-Backups der verwendeten Keys kann der Angreifer durch triviale Verbesserungen seiner Vorgehensweise umgehen. Insbesondere schützt es nicht, selbst kein Pinning einzusetzen. Schließlich kann ein Hacker mit ausreichenden Rechten auf dem Server HPKP ganz einfach selbst einrichten.

Der einzig wirklich wirksame Schutz gegen solche Angriffe wäre es, sich nicht hacken zu lassen. Doch wer kann das schon hundertprozentig ausschließen? Darüber hinaus könnte ein Monitoring-System Veränderungen an den HPKP-Headern des Servers beobachten und melden. So kann der Server-Betreiber wenigstens rechtzeitig einschreiten, wenn da Einträge auftauchen, die er nicht kennt.

Einschätzung und Ausblick

Die Kritik ist zwar zum Teil durchaus gerechtfertigt; HPKP deshalb für tot zu erklären, ist jedoch deutlich überzogen. So fehlt tatsächlich ein Schutz vor Erpressung mit unberechtigterweise gesetzten HPKP-Pins. Da muss nachgebessert werden. Dazu könnten etwa Browser-Hersteller einen Pin-Reset-Mechanismus einbauen. Dazu ruft der Browser analog zu den Listen böser URLs beim Hersteller regelmäßig eine (digital signierte) Liste böser HPKP-Pins ab, die er dann löscht. Aber auch andere Modelle wie die Beschränkung von HPKP auf CA-Pinning sind denkbar.

Die Kritik an der Komplexität und der damit verbundenen geringen Verbreitung teile ich hingegen nicht. Denn so schwierig ist das Einrichten von HPKP auch wieder nicht (siehe dazu etwa TLS wird sicherer durch Certificate Pinning und Zertifikats-Pinning auf dem eigenen Server in c't 23/2015). Und es wäre noch viel leichter, wenn die CAs beziehungsweise deren Reseller ihren Kunden aktiv dabei helfen würden. Die tatsächlich frustrierend niedrige Zahl von weniger als 3000 Sites, denen Netcraft funktionierendes HPKP bescheinigt, ist aus meiner Sicht viel mehr der mangelnden Bekanntheit des Standards geschuldet.

Außerdem ist das eigentlich Schöne an Certificate Pinning ja, dass es gar nicht viele einsetzen müssen, um Massenüberwachung in großem Stil unmöglich zu machen. Jeder einzelne Server, der sein Zertifikat via HPKP festnagelt, macht massenhafte Spionage durch Geheimdienste weniger wahrscheinlich. Denn mit jedem einzelnen HPKP-Web-Server, der auf einen Man-in-the-Middle-Angriff mit einer Fehlermeldung reagiert, steigt die Gefahr, dass solche Aktivitäten auffliegen.

Aber vielleicht braucht es ja doch einen neuen Anlauf. Da sieht der Entwurf zu TLS Server Identity Pinning with Tickets von Yaron Sheffer recht vielversprechend aus. Der hat zwar noch einen weiten Weg vor sich, hat aber für mein Gefühl allemal bessere Chancen als DANE für HTTPS und Browser. (ju)