HTTPS Public Key Pinning (HPKP)

Dieser Beitrag handelt von HPKP (HTTPS Public Key Pinning). HPKP verhindert wirksam „Man-in-the-middle“-Angriffe bei mit Zertifikaten geschützten Websites

Eigentlich schützt ein SSL/TLS-Zertifikat wirksam vor dem so genannten „Man-in-the-middle“-Angriff auf eine Website (bzw. auf einen Webserver). Schlecht nur, wenn das Zertifikat korrupt ist, was in den letzten Monaten leider häufiger vorgekommen ist. Da wurden von einigen CAs (Certification Authority; autorisierte Zertifizierungsstelle) Zertifikate ausgestellt für Domains, die dem Antragsteller gar nicht gehörten. Ein Zertifikat wird von einer CA ausgestellt, um dem eine Website aufrufenden Web-Browser zu bestätigen, dass die aufgerufene Domain tatsächlich die ist, die aufgerufen wurde. Niemand kann sich als https://dirkwolf.de ausgeben, außer die von einer CA zertifizierten Website https://dirkwolf.de. Das eine Website zertifiziert ist, erkennt man leicht daran, dass vor allen aufgerufenen Seiten https:// steht. Der Nutzer kann so sicher sein, dass er tatsächlich auf der Website https://dirkwolf.de ist, wenn er diese Domain aufruft. Außerdem werden Daten, die über diese Verbindung ausgetauscht werden, verschlüsselt. Das können bspw. Adressdaten sein, die eingegeben werden, um Infomaterial anzufordern oder die Kommentarfunktion unter diesem Beitrag.

Um dem Problem korrupter Zertifikate zu begegnen, ist nun eben jener neue Standard HPKP eingeführt worden. Ruft ein Nutzer eine Website, die mit HPKP geschützt ist erstmalig auf, wird dem aufrufenden Browser ein so genannter Pin übergeben, in dem zwei Schlüssel abgelegt sind und eine zeitlich Vorgabe. Der erste Schlüssel wird genutzt, um beim nächsten Aufruf zu prüfen, ob es sich tatsächlich um die richtige Website handelt. Hat ein anderer ein Zertifikat für die Domain erworben, nützt das nichts, weil er nicht den richtigen Schlüssel mitliefert, den der aufrufende Browser bei sich gespeichert hat. Der zweite Schlüssel dient als Backup, für den Fall, dass der erste Schlüssel kompromittiert wird. In diesem Fall würde der aufrufende Browser ansonsten die Website nicht mehr anzeigen. Die zeitliche Vorgabe (meist 60 Tage) dient dazu, dem Browser anzuweisen, 60 Tage lang den Schlüssel zu verlangen. Ruft der Nutzer die Website bspw. nach einer Woche erneut auf, beginnen die 60 Tage von vorn. Das sorgt dafür, dass nach einem Wechsel des Zertifikats, bspw. wenn das alte Zertifikat ausläuft, ein reibungsloser Übergang zum neuen Zertifikat gewährleistet wird. In diesem Fall wird einfach der alte Backup-Schlüssel als neuer erster Schlüssel definiert und ein neuer Backup-Schlüssel hinterlegt. Das erfordert jedoch eine saubere Hosting-Leistung, denn wird das beim Einbinden eines neuen Zertifikats vergessen, können alle regelmäßigen Besucher die Website nicht mehr sehen.

Der HPKP-Standard sieht außerdem vor, dass eine URL angegeben werden kann, an die eine Meldung abgesetzt wird, wenn ein Web-Browser den Aufruf einer Website abgelehnt hat, weil ein falscher Schlüssel verwendet wurde. So kann der Website-Betreiber feststellen, dass ein korruptes Zertifikat existiert.

Das Bild zeigt den HPKP-Eintrag von ssllabs.com
HPKP, dargestellt im Test von ssllabs.com

HPKP ist besonders sinnvoll im Zusammenhang mit (HSTS) Strict Transport Security. Darüber können Sie hier einen anderen Beitrag lesen.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.