HPKP: Das steckt hinter der Public-Key-Pinning-Erweiterung für HTTP

Sichere Übertragungskanäle sind eine wichtige Voraussetzung für die Arbeit mit digitalen Daten. Insbesondere, wenn Sie Datenpakete von unterwegs oder per Remote verschicken und erhalten, ist es von elementarer Bedeutung, dass der komplette Übertragungsweg gesichert ist. Nicht von ungefähr gehört es zur gängigen Praxis, vertrauliche Informationen ausschließlich über VPN- oder SSL/TLS-Verbindungen zu übertragen. Unternehmen und Einrichtungen sorgen mit eigenen DNS-Servern und ausgewählten Zertifizierungsstellen dafür, dass diese Protokoll-Technologien nahezu unantastbar sind. Nutzer, die außerhalb dieser Strukturen aktiv sind, unterliegen jedoch der öffentlichen DNS- und Zertifikatsstellen-Hierarchie, was die Wahrscheinlichkeit eines Man-in-the-Middle-Angriffs auf die Daten deutlich anhebt.

Hauptursache für das erhöhte Sicherheitsrisiko sind gefälschte Zertifikate, die von unseriösen oder infiltrierten Zertifikatsstellen ausgestellt werden. Der Nutzer vertraut also darauf, dass die Verbindung und alle Daten sicher sind, während die Vertrauen schaffende Instanz paradoxerweise dafür verantwortlich ist, dass das Gegenteil der Fall ist. Mit dem sogenannten HTTP Public Key Pinning (HPKP) brachte Google 2011 eine Lösung ins Spiel, die mittlerweile im RFC 7469 als Standard spezifiziert ist.

Beim Public Key Pinning handelt es sich um eine Erweiterung für das Übertragungsprotokoll HTTP (Hypertext Transfer Protocol), die es erlaubt, das Public-Key-Set für künftige SSL/TLS-Verbindungen zu einem Host festzulegen. Auf diese Weise erfährt ein zugreifender Client bei der ersten Kontaktaufnahme, welchen öffentlichen Schlüsseln er beim Verbindungsaufbau zu diesem Host vertrauen kann. Man spricht daher auch von einem „Trust on First Use“-Verfahren (dt. „Vertrauen bei der ersten Anwendung“). Jeder Eintrag eines verifizierten Schlüssels wird als Pin bezeichnet, woher der Mechanismus auch seinen Namen hat. Alle erstellten Pins werden dem Client im HTTP-Header übermittelt und daraufhin für den angegebenen Zeitraum gespeichert.

Bei einem erneuten Verbindungsgesuch überprüft der Client, ob die für die SSL/TLS-Übertragung vorgeschlagene Zertifizierungskette einen öffentlichen Key enthält, der ihm zuvor via HPKP zugespielt wurde. Ist dies nicht der Fall, beispielsweise bei einem gefälschten Zertifikat, kommt es zu einer Fehlermeldung und die Verbindung wird nicht aufgebaut. Diesen Überprüfungsprozess bezeichnet man auch als Pin-Validierung. Die Einträge der Pins im HTTP-Header sehen dabei in etwa folgendermaßen aus:

Das Beispiel zeigt alle vier Direktiven, die ein Pin-Eintrag im HTTP-Header enthalten kann:

• pin: Die pin-Direktive ist der wichtigste Bestandteil des Eintrags. Als solcher setzt sich die Direktive aus einem Namen und einem Wert zusammen. Der Name gibt Rückschlüsse auf den Algorithmus, der für die Verschlüsselung verwendet wurde. Bis dato ist hier einzig SHA256 möglich. Bei dem Hashwert, der sich innerhalb der Anführungszeichen befindet, handelt es sich um eine Base64-kodierte Zeichenfolge, die auch als Fingerprint bezeichnet wird. Für jeden Schlüssel (auch Back-ups) muss immer eine eigene pin-Direktive gesetzt werden.

• max-age: Die Direktive max-age gibt die Gültigkeitsdauer eines Pins in Sekunden an. Sie teilt dem Client also mit, wie lange er einen ausgezeichneten Public Key als sicheren Schlüssel werten soll. Im hier verwendeten Beispiel werden die aufgelisteten Pins nach 30 Tagen (2.592.000 Sekunden) verworfen.

• includeSubDomains: Die Anweisung includeSubDomains ist optional und erfordert keinen Wert. Sie signalisiert dem Client, dass die definierten Zertifizierungsregeln nicht nur für die aufgerufene Domain gelten, sondern auch für alle Subdomains, die zu dem Host gehören.

• report-uri: Wenn die Direktive report-uri gesetzt ist, werden jegliche Fehlversuche bei der Pin-Validierung an die angegebene URL gesendet. Diese muss sich nicht notwendigerweise auf derselben Internetdomain befinden wie der kontaktierte Host, der so über die fehlgeschlagenen Aufbauversuche informiert wird.

Um von den Möglichkeiten von HPKP Gebrauch zu machen, müssen Sie sich zunächst überlegen, welchen Public Key bzw. welche Public Keys Sie „pinnen“ möchten. Prinzipiell können Sie hierbei jeden öffentlichen Schlüssel auswählen, der in der Zertifizierungskette enthalten ist – egal ob Root-, Zwischen- oder das eigene Server-Zertifikat. Wählt man externe Zertifizierungsstellen aus, sollte man jedoch immer bedenken, dass in der Folge alle Zertifikate dieser Stelle von den Clients als gültig angesehen werden und zu einer erfolgreichen Pin-Validierung führen.

Wird der eigene Server-Key gepinnt, wiegt es dafür umso schwerer, wenn der Schlüssel unbrauchbar wird oder aufgrund eines Hardware-Defekts verloren geht. Da die Clients den Pin nämlich beim ersten Zugriff für die angegebene Gültigkeitsdauer gespeichert haben, akzeptieren sie vor Ablauf dieses Zeitrahmens auch keinen neuen Pin. Für die Nutzer wäre Ihr Server in der Folge nicht mehr erreichbar. Um diesem Szenario vorzubeugen, sieht der HPKP-Standard (RFC 7569) die zusätzliche Verwendung eines Back-up-Pins vor. Dieser wird ebenfalls über den HTTP-Header ausgeliefert und kann im Problemfall dazu genutzt werden, ein neues Zertifikat für die entsprechende Domain ausstellen zu lassen. Dieser Vorgang wird als Certificate Signing Request (CSR; dt. „Zertifikatsignierungsanforderung“) bezeichnet.

Pins der Public Keys berechnen

Soll HTTP Public Key Pinning auf Ihrem Server funktioniert, ist es notwendig, dass HTTPS bereits konfiguriert ist. Da mindestens zwei öffentliche Schlüssel gepinnt werden müssen, steht die Generierung dieser Pins im ersten Schritt auf dem Programm. Die einfache Lösung, um die Hashwerte existierender Public Keys zu errechnen, ist die Open-Source-Anwendung openssl, die Sie über die Kommandozeile Ihres Systems nutzen können. Als Standardbefehl für X.509-Zertifikate gibt RFC 7469 vor:

Auf diese Weise erzeugen Sie für das Beispiel-Zertifikat certificate.pem die Base64-Sequenz für den Schlüssel public.key. Diese wird auf der Standardausgabe ausgegeben und endet immer auf dem Gleichheitszeichen („=“).

Im nächsten Schritt richten Sie den Certificate Signing Request (hier: backup.csr) für Ihren Back-up-Key (hier: backup.key) ein:

Anschließend lassen Sie sich mithilfe von openssl auch den Hashwert dieses Schlüssels errechnen:

Sicherung des Back-up-Pins

Da der HPKP-Back-up-Key den Standardschlüssel bei einem Ausfall ersetzen soll, ist es sinnvoll, diesen separat aufzubewahren. Im besten Fall wählen Sie hierfür eine externe Speicherplattform, die Sie jederzeit und von überall aus erreichen können. Ferner ist die Nutzung eines Passwort-Managers zu empfehlen: Wenn Sie den Certificate Signing Request und den dazugehörigen Schlüssel mithilfe einer solchen Software zusätzlich in einer eigenen Datenbank absichern, sind Sie auf der sicheren Seite – und der bzw. die Back-up-Schlüssel im entscheidenden Moment zum Einsatz bereit.

Dank dem „Trust on First Use“-Ansatz greift HPKP bereits im Anschluss an die erste Kontaktaufnahme durch den Client. Der erste Besuch, bei dem der Server die gepinnten Keys übermittelt, ist jedoch durch das Verfahren selbst nicht geschützt. Diese kleine Lücke führt aber nur in Einzelfällen zu Problemen, während eine größere Zahl unbemerkter Angriffe auf die SSL/TLS-Verbindungen Ihres Webprojekts nahezu ausgeschlossen ist. Der Hauptkritikpunkt, der gegen das Public Key Pinning hervorgebracht wird, betrifft folgendes Angriffsszenario, das erst durch denEinsatz der Pinning-Technikmöglich wird:

1. Ein Angreifer verschafft sich Zugriff zu Ihrem Server.
2. Er installiert ein neues SSL/TLS-Zertifikat und erstellt im Anschluss ein eigenes Schlüsselpaar.
3. Für den Public Key generiert er nun außerdem den passenden Hash-Wert und trägt diesen anstelle Ihrer Pins in den entsprechenden Bereich im Certificate-Pinning-Header ein.
4. Anwender bzw. Clients, die Ihr Webprojekt zum ersten Mal aufrufen, erhalten nun den falschen Pin und können in der Folge keine gesicherte Verbindung zu Ihrem Server aufbauen.
5. Löscht der Angreifer das Zertifikat nun wieder von Ihrem Server, bleibt diesen Nutzern der Zutritt zu Ihrer Seite verwehrt, bis die Gültigkeitsdauer des falschen Pins abgelaufen ist.
6. Außer Ihnen auf diese Weise bloßen Schaden durch den entstehenden Traffic-Verlust zuzufügen, hat der Angreifer in der Theorie auch die Möglichkeit, Geld für die Freigabe des falschen Zertifikats zu verlangen und Sie auf diesem Weg zu erpressen.

Auch wenn dieses Szenario theoretisch möglich ist, ist es noch lange kein Argument gegen den Einsatz von HTTP Public Key Pinning. Denn der Angreifer könnte die Erweiterung des HTTP-Protokolls ebenso gut selbst einrichten, sobald er sich Zugriff zum Server verschafft hat. Das Problem stellt letztlich nur unter Beweis, wie wichtig es ist, das Sie Ihr Projekt gegen Hackerangriffe schützen. Wenn Sie Pins einsetzen, sollten Sie darüber hinaus auch Ihre Monitoring-Software dahingehend sensibilisieren, dass Sie bei Veränderungen in den HPKP-Headern umgehend informiert werden, um rechtzeitig einschreiten zu können. Ein denkbarer Lösungsansatz auf Seiten der Clients wären Pin-Reset-Mechanismen, die bekannte „bösartige“ Pins regelmäßig löschen.

Andere negative Kritikpunkte sind zumeist die geringe Verbreitung und die Komplexität, die mit der Konfiguration des Public Key Pinnings verbunden ist. Die Ursachen hierfür liegen vermutlich vor allem darin, dass der Standard häufig nur schlecht bzw. gar nicht bekannt ist.