HTTP Public Key Pinning sicher einsetzen

HTTP Public Key Pinning (HPKP) ist ein Verfahren zur Absicherung gegen Man-in-the-Middle-Angriffe, die durch unzulässig ausgestellte Zertifikate möglich werden. Ein prominenter Angriff war der Fall von Diginotar, bei dem diese Zertifizierungsstelle gültige Zertifikate für Domains wie google.com oder www.cia.gov an iranische Hacker ausgestellt hatte. Die Hackergruppe konnten in der Folge verschlüsselte Verbindungen abhören und dadurch in Besitz weiterer sensitiver Daten gelangen. Der Angriff aus dem Jahr 2011 ist deshalb aufgefallen, weil Google kurz vor dem Vorfall Zertifikatspinning als neue Sicherheitsfunktion in seinen Chrome-Browser eingebaut hatte.

Bei HTTP Public Key Pinning können einem Browser durch sogenannte Pins mitgeteilt werden, welche Zertifikate für die Absicherung einer verschlüsselten Verbindung zulässig sind. Die Pins – ein Fingerabdruck der SPKI – werden als HTTP-Header in der Antwort des Servers übertragen (vgl. Codebeispiel 1). Ähnlich wie bei HSTS handelt es sich hier um ein TOFU-Verfahren (Trust On First Use): Beim ersten Aufruf des Browsers weiß dieser noch nichts über eine Einschränkung durch Pins. Er baut eine verschlüsselte Verbindung mit dem Server auf und wird anschließend darüber informiert, dass gemäß der Public Key Pins nur eine Auswahl an Zertifikaten zum Aufbau der verschlüsselten Verbindung zulässig ist. Für nachfolgende Verbindungen wird der Browser nur noch Zertifikate für verschlüsselte Verbindungen akzeptieren, die mit den gespeicherten Public Key Pin-Informationen übereinstimmen. Damit können Verbindungen vor Angriffen wie im eingangs beschriebenen Diginotar-Fall geschützt werden.

Public-Key-Pins:
  pin-sha256="ygFAna6QwOObKwAP+LJvDLGD2MRxKQTko04tQIPZuJk=";
  pin-sha256="H9peR7D23RgyX47aT8syA8i1iZ3zr4vNiTU659U0nm4=";
  max-age=2592000; 
  report-uri="https://example.com/pkp-report"

Vertrauensproblem der Public Key Infrastruktur gelöst

Durch HPKP ist es einem Betreiber einer Webseite möglich explizit zu definieren, welche Zertifikate für eine verschlüsselte Verbindung zulässig sind. Lässt man den TOFU-Umstand außer Acht, löst dieses Verfahren das Vertrauensproblem der Public Key Infrastruktur. Der Browser weiß vor dem Aufruf einer Domain, welche Zertifikate er akzeptieren darf. Antwortet der Server mit einem unbekannten Zertifikat, lehnt dieser die Verbindung ab. Solch ein Segen kann natürlich auch schnell zum Fluch werden: Kann ein Betreiber einer Webseite keines der Zertifikate zu den vorab kommunizierten Pins mehr verwenden – aus welchen Gründen auch immer – lehnen Browser andere Verbindungsversuche ab. Die Webseite ist bis zum Ablauf der Pin-Informationen nicht mehr zu verwenden.

Absicherung vor Selbst-DoS

In Anbetracht eines solchen Szenarios gilt es mehrere Dinge zu berücksichtigen und Risiken gegeneinander abzuwägen. Wer seine eigenen Zertifikate pinnt, muss ständig den ausgelieferten Public-Key-Pins-Header überprüfen. Einer von beiden Pins muss dem aktuell verwendeten Zertifikat gehören; der andere Pin muss dem offline, an einem sicheren Ort gespeicherten Zertifikat entsprechen. Ebenso muss der rollierende Erneuerungsprozess der Pins zunächst getestet und später regelmäßig geprüft werden. Glücklicherweise bietet der Mechanismus die Möglichkeit einen Public-Key-Pins-Report-Only-Header einzusetzen. Damit wird die Policy nicht zwingend durchgesetzt, Verstöße dagegen können jedoch an eine URL gesendet werden.

Wer weniger Risiko eingehen möchte, kann auch andere Zertifikate pinnen, die in der Zertifikatskette der Serverantwort ausgeliefert werden. Es ist möglich das Zwischen- oder das Wurzelzertifikat seines Zertifikatanbieters zu pinnen. Dadurch gibt man etwas mehr Kontrolle darüber ab, welches Zertifikat verwendet werden darf. Allerdings beschränkt man die Menge an potentiell zulässigen Zertifikaten auf diejenigen, die durch das Zwischen- bzw. Wurzelzertifikat signiert wurden, und das ist immer noch besser als der Status Quo: allen Zertifizierungsstellen zu vertrauen.