Gelegentlich laufen einem Technologien über den Weg, die man eigentlich schon länger tief im Hinterkopf verstaut hatte, weil sie inzwischen überholt sind. Vor kurzem beispielsweise war in der Beispiel-Konfigurationsdatei eines Softwarepakets noch HTTP Public Key Pinning (HPKP) beschrieben.
Was ist das, wofür sollte es einmal gut sein, und warum verwendet man es heute nicht mehr? HPKP war eine Methode, um bestimmte Angriffsszenarien mit Zertifikaten zu erschweren. Die meisten Websites verwenden heutzutage eine Transportverschlüsselung auf Basis von TLS, erkennbar am Protokollvorspann https:// statt http://. Das ist inzwischen so zum Alltag geworden, dass viele Browser nicht mehr wie früher positiv hervorheben, wenn die Verbindung zur angezeigten Website verschlüssel ist, etwa mit einem grünen Schloss. Stattdessen wird gewissermaßen negativ angemerkt, wenn die Verbindung nicht verschlüsselt ist.
Technisch stecken hinter HTTPS unter anderem Zertifikate. Mit einem Zertifikat kann ein Webserver bestätigen, dass er beispielsweise tatsächlich www.isatis-online.de ausliefert, und das nicht nur behauptet. Außerdem ist ein solches Zertifikat Teil eines Schlüsselpaares, wie wir es bereits vor einiger Zeit beschrieben haben. Mit diesem Schlüsselpaar kann der Datenverkehr auf dem Weg zwischen Webbrowser und Webserver verschlüsselt werden, eben als Transportverschlüsselung.
Für HPKP ist jedoch die “Bestätigungsfunktion” eines Zertifikats relevant. Dabei wird eine “Vertrauenskette” (chain of trust) aufgebaut. Denn woher “weiß” der Webbrowser, dass er dem Zertifikat, das der Webserver vorzeigt, vertrauen kann? Zertifikate werden von Zertifizierungsstellen (certificate authorities oder CAs) ausgestellt. Wenn der Browser der Zertifizierungstelle vertraut, dann vertraut er implizit auch den Zertifikaten, die dort ausgestellt wurden. Häufig gibt es ein oder mehrere sogenannte Zwischenzertifikate: Der Browser vertraut dem Zertifikat der Website, weil es vom Zwischenzertifikat signiert wurde, und der Browser dem Zwischenzertifikat vertraut. Und der Browser vertraut dem Zwischenzertifikat, weil das von einer CA signiert wurde, und der Browser der CA vertraut. Und der Browser vertraut der CA, weil…
Weil die in dieser Form aufgebaute Vertrauenskette zu einem der Wurzelzertifikate (root certificates) führt. Denn ein Webbrowser, aber auch andere Clients wie Mailprogramme, bringen eine Reihe von Zertifikaten mit, die als vertrauenswürdig vorausgesetzt werden. Wenn eine Website also ein Zertifikat vorzeigt, und dieses Zertifikat auf die beschriebene Weise auf ein Wurzelzertifikat “zurückgeführt” werden kann, kann der Browser dem Zertifikat der Website vertrauen.
So weit, so gut. Aber was ist, wenn eine Zertifizierungsstelle in irgendeiner Form kompromittiert wird? Sowas ist tatsächlich schon passiert. Zum Beispiel wurde 2011 entdeckt, dass Angreifer in die Infrastruktur der Zertifizierungstelle DigiNotar eingedrungen waren, und mehrere hundert Zertifikate ausgestellt hatten. Diese Zertifikate waren gefälscht, aber technisch gültig, weil von DigiNotar signiert.
Mit solchen Zertifikaten konnten leicht sogenannte Man-in-the-Middle-Angriffe durchgeführt werden: Ein Angreifer schaltet sich im Netzwerk zwischen Webbrowser und Webserver und “erzählt” jedem von beiden, er sei der jeweils andere. Dabei kann er die gesamte Kommunikation zwischen den beiden Partnern entschlüsseln und mitschneiden.
Natürlich wurden nach der Entdeckung des Angriffs die Wurzelzertifikate von DigiNotar aus den diversen Clients entfernt. Das dauert aber seine Zeit, unter anderem, weil nicht jeder Anwender regelmäßig seinen Webbrowser aktualisiert. Und was passiert in der Zwischenzeit? Dieses Problem sollte HPKP lösen.
Dazu wird ein neuer HTTP-Header namens Public-Key-Pins eingeführt. Mit diesem Header kann eine Website diejenigen Zertifikate auflisten, die ein Browser akzeptieren soll. Das heißt dann, ein Browser akzeptiert nicht mehr alle Zertifikate für die jeweilige Domain, die eine chain of trust vorweisen können (und noch nicht abgelaufen sind etc.), sondern nur diejenigen, die in Public-Key-Pins genannt sind. Wenn also ein Angreifer es irgendwie schafft, sich mit einem gefälschten Zertifikat “in die Mitte zu setzen”, steht dieses Zertifikat noch lange nicht in der Liste in Public-Key Pins.
Was in der Theorie nach einer guten Idee klingt, erwies sich in der Praxis aber schnell als problematisch. Beispielsweise ist die Syntax von Public-Key-Pins recht komplex, was zu vielen Fehlkonfigurationen führte. Das kann im Extremfall zu der Situation führen, dass man sich selbst aus seiner Website “aussperrt”. Denn wenn man den Server über den Browser konfiguriert, und der Browser einen aufgrund der Fehlkonfiguration nicht mehr auf die Website lässt, tja… In bestimmten anderen Szenarien kann es außerdem dazu kommen, dass gar kein Zertifikat mehr akzeptiert wird, und die Website nicht mehr aufgerufen werden kann. Sogar “Schutzgelderpressungen” sind möglich, wenn etwa ein Angreifer es schafft, die Liste in Public-Key-Pins gegen eine mit von ihm kontrollierten Zertifikaten auszutauschen.
Entsprechend haben die meisten Browser die Unterstützung für HPKP ab etwa 2020 beendet. Der Mechanismus ist damit heute obsolet.
Das Problem mit versehentlich oder böswillig “fehlausgestellten” Zertifikaten besteht aber natürlich weiter. Inzwischen hat sich eine andere Lösung etabliert, nämlich die Certificate Transparency (CT). Das ist, kurz gesagt, ein revisionssicheres Verzeichnis, in dem der Webbrowser nachschlägt, ob das vom Server vorgezeigte Zertifikat noch immer vertrauenswürdig ist. Bisher unterstützen noch nicht alle Browser oder alle Zertifizierungstellen CT, aber unter anderem Google, Cloudflare, DigiCert und Let’s Encrypt sind bereits dabei.
