Rote Stecknadel

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.

Public Key Pinning
Abbildung 1 Alice vertraut nur noch gĂŒltigen Zertifikaten, wenn die in ihrem Browser gespeicherten SPKI-FingerabdrĂŒcke mit denen des Zertifikats ĂŒbereinstimmen.

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"
Codebeispiel 1 Public Key-Pins als HTTP-Header mit einer GĂŒltigkeit von 30 Tagen (2.592.000 Sekunden)

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.

Wir begleiten Sie gerne auf dem Weg der sicheren IT. Bitte senden Sie uns eine Anfrage per E-Mail. Wir rufen Sie zeitnah zurĂŒck und klĂ€ren mit Ihnen die Details fĂŒr ein verbindliches Angebot ab.