HPKP – Alles was Sie wissen müssen

Key Pinning – Der Schutz vor beeinträchtigten Zertifizierungsstellen

Wie funktioniert das Public Key Pinning?

Public Key Pinning gehört zu den Verfahren, die die Sicherheit von SSL-Zertifikaten immens erhöhen können. Zweck ist es, festzustellen, wann sich der öffentliche Schlüssel eines Zertifikats für einen bestimmten Host geändert hat. Dies kann etwa dann passieren, wenn ein Angreifer eine CA dermaßen beeinträchtigt, dass gültige Zertifikate für beliebige Domains ausgegeben werden können. Ein recht prominentes Beispiel dafür war die Ausstellung falscher Microsoft-Zertifikate, über das wir in unserem Blog berichtet haben.

Ist eine TLS-Verbindung mit dem Server hergestellt, sucht der Browser jede gespeicherte Pin für den jeweiligen Hostnamen heraus und prüft, ob einer der gespeicherten Pins mit denen des SKPK-Fingerprints (= Ergebnis der SHA256-Anwendung auf die Public Key-Info) in der Zertifikatskette übereinstimmt. Scheitert diese Pin-Verifizierung, so muss die Verbindung sofort abgebrochen werden. Ist serverseitig kein HPKP konfiguriert oder unterstützt der Browser HPKP nicht, kommt die Verbindung dennoch zustande.

Wie wird gepinnt?
Step-by-step Anleitung beim Apache Webserver

Private Keys generieren (einen primären und eine backup Key)

openssl genrsa -out www.hpkp-faq.de.key1.key 2048
openssl genrsa -out www.hpkp-faq.de.key2.key 2048

CSRs erstellen (für beide private Keys)

openssl req -new -sha256 -key www.hpkp-faq.de.key1.key -out www.hpkp-faq.de.csr
openssl req -new -sha256 -key www.hpkp-faq.de.key2.key -out
www.hpkp-faq.de.backup-csr.csr

SPKI Fingerprints von beiden Public Keys generieren

openssl req -pubkey < www.hpkp-faq.de.csr | openssl pkey -pubin -outform der |
openssl dgst -sha256 -binary | base64
hIBFVXDUBPQgeRapi9mRB7127NhGkTc+QS4EHq2LyBA=
openssl req -pubkey < www.hpkp-faq.de.backup-csr.csr | openssl pkey -pubin -outform der |
openssl dgst -sha256 -binary | base64
ZrYB07EvOX0HjbBTjJp3lEMt22nGJGqYDGU21ZnBzb8=

virtual Host Konfiguration anpassen

Header always set Public-Key-Pins: ‚max-age=5184000
pin-sha256=“hIBFVXDUBPQgeRapi9mRB7127NhGkTc+QS4EHq2LyBA=“;
pin-sha256=“ZrYB07EvOX0HjbBTjJp3lEMt22nGJGqYDGU21ZnBzb8=“‘

Pinnen der beiden Public Keys

Alternativ gibt es die Möglichkeit vorab im Testmodus zu starten. Hierfür geben Sie „Header always set Public-Key-Pins-Report-Only“ anstatt „Header always set Public-Key-Pins“ an:

Header always set Public-Key-Pins-Report-Only: ‚max-age=5184000;
pin-sha256=“hIBFVXDUBPQgeRapi9mRB7127NhGkTc+QS4EHq2LyBA=“;
pin-sha256=“ZrYB07EvOX0HjbBTjJp3lEMt22nGJGqYDGU21ZnBzb8=“‘

Reporting anschalten

Beim HTTP Public Key Pinning gibt es die Möglichkeit sich vom zugreifenden Browser, Fehlermeldungen anzeigen zu lassen. Allerdings wird dies erst mit dem Chrome Version 46 unterstützt. Die persönliche URI wird mit dem Flag „report-uri“ ebenfalls in die virtual Host Konfiguration eingebaut:

Header always set Public-Key-Pins:
max-age=5184000; 
pin-sha256=“hIBFVXDUBPQgeRapi9mRB7127NhGkTc+QS4EHq2LyBA=“; 
pin-sha256=“ZrYB07EvOX0HjbBTjJp3lEMt22nGJGqYDGU21ZnBzb8=“; 
report-uri=
“https://report-uri.io/report/559ec66014bc9434bab6626345a017f3“‘

Über Qualys ssllabs Test können Sie Ihre Konfiguration testen. Nutzen Sie hierfür: https://www.ssllabs.com/ssltest/ oder vorzugsweise https://dev.ssllabs.com/ssltest/.

HTTP-Erweiterung HPKP:
wie soll der Header aussehen?

Mittels curl – I https:// www.beispiel.de können Sie sich den Header auf der Konsole anzeigen lassen.

Der HTTP Header kann wie folgt aussehen:

HTTP/1.1 200 OK
Date: Thu, 12 Nov 2015 10:45:37 GMT
Server: Apache
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
Public-Key-Pins: max-age=5184000; pin-sha256=“hIBFVXDUBPQgeRapi9mRB7127NhGGkT
c+QS4EHq2LyBA=“;
pin-sha256=“ZrYB07EvOX0HjbBTjJp3lEMt22nGJGqYDGU21ZnBzb8=“;
report-uri=“https://report-uri.io/report/559ec66014bc9434bab6626345a017f3“
X-Powered-By: PHP/5.5.30
Content-Type: text/html; charset=UTF-8

Der Header spezifiziert mindestens pin-sha256 Werte, d. h.: die Pins von zwei öffentlichen Schlüsseln. Dabei ist ein Pin der eines beliebigen öffentlichen Schlüssels, der sich in der aktuellen Zertifikatskette befindet, der andere ist der eines beliebigen öffentlichen Schlüssels, der sich nicht in der aktuellen Zertifiktaskette befinden muss. Bei letzterem könnte es sich einen Backup-Key handeln, der beispielsweise dann zum Einsatz kommt, wenn Ihr Zertifikat abläuft oder zurückgezogen werden muss.

Welche Informationen enthält das Zertifikat?

Senden Sie die Certificate Signing Request (CSR) mit Ihrem Public Key an eine Zertifizierungsstelle, stellt Ihnen diese ein gültiges Zertifikat aus. Dieses enthält den öffentlichen Schlüssel des RSA-Schlüsselpars sowie ein Ablaufdatum. Sowohl der öffentliche Schlüssel als auch das Ablaufdatum werden von der Zertifizierungsstelle signiert, sodas jedwede Veränderungen an diesen beiden Komponenten das Zertifikat sofort ungültig werden lassen. X.509-Zertifikate enthalten auch andere Bereiche, um TLS-Verbindungen vernünftig zu authentifzieren, etwa den Hostnamen Ihres Servers sowie weitere Details.

Wie können RSA-Schlüssel erstellt werden?

Mit dem Befehl

openssl genrsa 2048

erzeugen Sie einen 2.048-bit-RSA-Schlüssel und geben ihn auf der Konsole aus. Wenngleich es -----BEGIN RSA PRIVATE KEY----- heißt, wird nicht ausschließlich der private Schlüssel ausgegeben, sondern auch die ASN.1-Struktur, die ebenfalls einen Public Key enthält. So erzeugen Sie also ein RSA-Schlüsselpaar. Ein weit verbreiteter Irrtum in der Kryptographie besteht darin, dass der RSA-Schlüssel selbst für ein bestimmtes Zertifikat ablaufen kann. RSA-Schlüssel laufen jedoch nie ab – es sind letztlich nur Zahlen. Das Zertifikat jedoch, das den Public Key enthält, kann sehr wohl ablaufen. Deshalb kann auch nur das Zertifikat zurückgezogen werden. Die Schlüssel selbst laufen ab oder werden zurückgezogen, sobald es keine gültigen Zertifikate mehr gibt, die eben diesen öffentlichen Schlüssel verwenden, oder wenn Sie den Schlüssel vernichtet haben oder überhaupt aufgehört haben, diesen zu verwenden.

Was tun, wenn Sie Ihr Zertifikat
ersetzen müssen?

Läuft Ihr Zertifikat ab oder wurde Ihr privater Schlüssel kompromittiert, müssen Sie Ihr Zertifikat womöglich zurückziehen, in jedem Fall aber ersetzen. Dies kann dazu führen, dass Ihre Pin ungültig wird: die Beschränkungen, die beim Kauf eines neuen gültigen Zertifikat existieren, sind dieselben, vor denen Angreifer stehen, die versuchen, Ihre Identität anzunehmen und Ihre TLS-Sitzung abzufangen.

Die Pin-Verifikation verlangt, dass sämtliche SPKI-Fingerprints aller Zertifikate einer Kette überprüft werden, und sie gelingt in dem Moment, in dem einer der Public Key zu einem der Pins passt. Nehmen wir an, Zertifizierungsstelle XY hat Ihr Zertifikat signiert und Sie haben ein weiteres Class 1- oder Class 2-Zwischenzertifikat sowie deren Root-Zertifikat in der Kette: der Browser vertraut ausschließlich dem Root-Zertifikat, jedoch werden die Zwischenzertifikate vom Root-Zertifikat signiert. Das Zwischenzertifikat wiederum signiert das auf den Server ausgelieferte Zertifikat. Dies nennt man Vertrauenskette. Haben Sie nun Ihr Zwischenzertifikat gepinnt, ist die einzige Option der Wiederherstellung der Backup-Key. Auf was auch immer dieser verweist, muss im neuen Zertifikat gespeichert sein, wenn Sie jene Benutzer auf Ihrem Server wieder zulassen möchten, die Ihre Pin aus vorherigen Sitzungen gespeichert haben.

Eine einfachere Lösung wäre sicherlich, wenn Sie den SPKI-Fingerprint aus dem Zwischenzertifikat Class 1 verfügbar zu machen. Um eine neue und gültige Zertifikatskette zu schaffen, bitten Sie Ihre Zertifizierungsstelle, ein neues Zertifikat für einen neuen oder Ihren aktuellen Schlüssel auszustellen. Mit einer etwas größeren Angriffsfläche zahlen Sie jedoch einen Preis dafür, denn jemand, der den Private Key des Zwischenzertifikats gestohlen hat, wäre nun in die Lage versetzt, Ihre Seite zu imitieren und Key Pinning-Prüfungen erfolgreich zu durchlaufen.

Eine andere Option besteht darin, das Wurzelzertifikat zu pinnen. Jedes beliebige, durch die CA ausgestellte Zertifikat würde es Ihnen erlauben, eine neue gültige Zertifikatskette zu erstellen. Auch dadurch würde sich die Angriffsfläche dezent erhöhen, da jedes beeinträchtigte Zwischen- oder Wurzelzertifikat es gestatten kann, Ihre Seite zu imitieren und Pinning-Checks zu bestehen.

Welcher Schlüssel soll gepinnt werden?

In Anbetracht all der genannten Szenarien fragen Sie sich vielleicht, welchen Schlüssel Sie am besten fürs Pinnen verwenden, und die Antwort kann nur lauten: das kommt drauf an. Sie können einen oder alle öffentlichen Schlüssel in Ihrer Zertifikatskette pinnen, und das wird funktionieren. Die Spezifikation verlangt, dass Sie mindestens zwei Pins haben, sodass Sie den SPKI-Hash eines anderen Rootzertifikats einfügen müssen, ein anderes Zwischenzertifikat (eine andere Stufe Ihrer aktuellen CA würde auch funktionieren) oder ein anderes untergeordnetes Zertifikat. Die einzige Anforderung ist: der Pin entspricht nicht dem Hashwert von irgendeinem Zertifikat innerhalb der aktuellen Kette. Der Browser kann nicht feststellen, ob Sie ihm ein gültiges, sinnvolles Backup bereitgestellt haben - weshalb er auch gerne Zufallswerte akzeptiert.

Beim Pinnen auf eine kleine Auswahl von CAs zurückzugreifen, bei denen Sie sich wohl und sicher fühlen, hilft Ihnen, das Risiko einzuschränken. Beim Pinnen nur Ihre untergeordneten Zertifikate zu verwenden, birgt ein erhöhtes Risiko, bietet jedoch mehr Sicherheit. Es ist ein bisschen wie Fahren ohne Gurt: es funktioniert meistens, aber falls etwas schief geht, geht es in aller Regel so richtig schief. Und das wollen Sie sicherlich vermeiden.

Wenn Sie ausschließlich Ihre untergeordneten Zertifikate pinnen, besteht außerdem die Gefahr, dass Sie einen Backup-Schlüssel generieren, der an Uraltstandards festhält und vielleicht nicht mehr benutzt werden kann, wenn Sie Ihr aktuelles Zertifikat ersetzen müssen. Drehen wir die Uhr drei Jahre zurück. Ihr Backup-Key ist ein 1.024-Bit-RSA-Schlüsselpaar. Sie pinnen für ein Jahr, dann läuft das Zertifikat ab. Sie gehen zur CA und bitten um ein neues Zertifikat für Schlüssel A, die CA sagt jedoch, dass der Schüssel ist zu kurz und zu schwach ist. Sie fragen nach dem Backup-Schlüssel, der ebenfalls zurückgewiesen wird, weil er zu kurz ist. Ergebnis: Weil Sie beim Pinnen nur von Ihnen kontrollierte Schlüssel verwendet haben, sind sie nun quasi eingemauert bzw. sperren potenzielle Besucher Ihrer Website aus.

Maßnahmen zum Schutz gegen
unberechtigt ausgestellte Zertifikate

Fragen/Problem	CT (Certificate Transparency)	CAA (Certificate Authority Authorization)	Pinning
Fähigkeit, vor der Ausgabe von gefälschten Zertifikaten zu schützen		Eingeschränkt - abhängig von den CAA Geschäftsbedingungen, Einhaltung durch alle CAs
Fähigkeit, gefälschte Zertifikate nach der Ausgabe zu erkennen	Hoch - aber nur, wenn der Eigentümer der Zieldomain alle CT-Logs überwacht (mögliche Verzögerung bis zur Entdeckung)		Hoch - Chrome´s hard-coded PINs haben erfolgreich schwere Fälle von Ausgaben falscher Zertifikate erkannt
Fähigkeit, gefälschte Zertifikate nach der Ausgabe/Erteilung zu erkennen - in Ländern mit geschlossenem oder überwachtem DNS (Domain Name System)	Hoch - Zertifikat muss in mehreren öffentlichen Logs enthalten sein, andernfalls werden die Browser die aufegerufene Seite nicht verschlüsselt aufrufen können		Eingeschränkt - Browser können die Seiten nicht verschlüsselt aufrufen, könnten aber auch nicht in der Lage sein, den Fehler zu melden
Hard-Fail zum Schutz des Users?	Ja (wenn das Zertifikat nicht durch CT-Logs signiert wurde) - aber gefälschte Zertifikate, die durch das CT-Logs signiert wurden, werden als gültige Zertifikate behandelt, kein hard-fail		Ja - hard-fail, die Seite wird nicht verschlüsselt aufgerufen werden können
Widerrufbarkeit von gefälschten Zertifikaten	verbessert die Möglichkeit, die Ausgabe von falschen Zertifikaten zu erkennen, aber nur wenn der Domaininhaber die CT Logs überwacht	Keine Änderung des aktuellen Systems. Keine einfache Möglichkeit für den Besitzer oder den Nutzer, gefälschte Zertifikate zu erkennen.	HPKP (HTTP Public Key Pinning) (unter der Annahme eines hard-fail) entspricht einer Annulierung des nicht gepinnten Zertifikats (von der CA zurückgezogene Zertifikate)
Potenzielle Verzögerung / Leistungs-Probleme	Nein - bezogen auf die Benutzer, aber die CT-Logs müssen hochverfügbar sein, sonst stellen die CAs keine Zertifikate aus (erzeugt eine neue Abhängigkeit)
DOS-Probleme	Mögliche Probleme - wenn die CT-Logs geblockt sind, können keine Zertifikate ausgegeben werden und die CT Logs können in den entscheidenden Momenten nicht überwacht werden - aber es existieren mehrere CT Logs
Skalierbarkeitsprobleme	Signifikant - wenn Hochverfügbarkeits-Infrastruktur vorhanden ist, dann ist die Skalierbarkeit gegeben		Nein - HPKP kann derzeit PINs in Browsern wie Chrome festcodiert skalieren
Probleme bei der Privatspäre von Benutzern	Hoch - alle ausgestellten Zertifikate würden sofort für die Öffentlichkeit zugänglich und könnten kopiert werden	Niedrig - CA Voreinstellungen für Domains sind in einem öffentlich zugänglichen DNS-Eintrag ersichtlich	Niedrig - Hashes von öffentlichen Schlüsseln der Websites sind im DNS-Record ersichtlich
Anforderungen an CAs	Hoch (Komplex, ungewisse Kosten, schafft externe Abhängigkeiten)	Mittel (abhängig von den vereinbarten Geschäftsregeln) zusätzliche Kundenkommunikation wird benötigt, potenzieller Konkurrenzkampf	Niedrig - CAs müssen den Kunden vermitteln, wie sie mit den Auswirkungen beim Ändern von Zwischen- oder Stammzertifikaten umzugehen haben (wenn Zwischen- oder Stammzertifikate genutzt wurden)
Anforderungen an den Browser	Hoch (für den User-Agent des Browser müssen die gewählten CT-Logs ausgewiesen werden, denen er vertrauet. Diese Logs müssen geprüft werden und es muss sichergestellt werden, dass dieser Agent Zertifikate anhand der CT-Logs überwacht)		Eingeschränkt - Browser Benutzerprogramme müssen geändert werden, um den Benutzerschlüssel Hash mit den Pinning Informationen im DNS, den gespeicherten PINs, Warnungsanzeigen oder hard-fail zu überprüfen
Anforderungen an Domain-Inhaber	Eingeschränkt (Eigentümer, die Wert darauf legen, ihre CT-Logs selber zu überwachen oder für den Überwachungsservice zu bezahlen. Alle Unternehmen müssen eine zentrale Aufzeichnun über alle gültigen Zertifikate ihrer Organisation haben) CT erfordert, dass alle DomainEigentümer durch die Auflistung ihrer Zertifikate in den öffentlichen CT-Logs teilnehmen	Eingeschränkt für teilnehmende DomainBesitzer - es müssen alle erlaubten CAs in allen DNS-Einträgen aufgelistet sein	Hoch für teilnehmende DomainBesitzer - Domain-Inhaber müssen alle Pinning-Aufzeichnungen für alle gültigen Zertifikate aktualisiert auf allen Servern bereit halten, sonst könnte der Zugang zur Website blockieren