Telefonischer Support
0800/503750-1
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 die 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 SPKI-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.
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:
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 URL wird mit dem Flag „report-uri“ ebenfalls in die virtual Host Konfiguration eingebaut:
Ü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/.
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:
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.
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üsselpaars sowie ein Ablaufdatum. Sowohl der öffentliche Schlüssel als auch das Ablaufdatum werden von der Zertifizierungsstelle signiert, sodass 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.
Mit dem Befehl
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.
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 Root-Zertifikat 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 Root-Zertifikat es gestatten kann, Ihre Seite zu imitieren und Pinning-Checks zu bestehen
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.
| 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, andernsfalls werden die Browser die aufgerufene Seite nicht verschlüsselt aufrufen können | | Eingeschränkt - Browser können die Seiten nicht verschlüsselt aufrufen, sind aber auch nicht in der Lage, 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 Zertifiakten | 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 Annullierung 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 entscheidenen 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 Voreinstellung 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 Stammzertiifkate 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 vertraut. Diese Logs müssen geprüft werden und es muss sichergestellt werden, dass dieser Agent Zertiifkate anhand der CT-Logs überwacht) | | Eingeschränkt - Browser Benutzerprogramme müssen geändert werden, um den Benutzerschlüssel Hash mit dem Pinning Informationen im DNS, den gespeicherten PINs, Warnungsanzeigen oder hard-fail zu überprüfen |
| Andorderungen 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 Aufzeichnung ü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 Domain-Besitzer - es müssen alle erlaubten CAs in allen DNS-Einträgen aufgelistet sein | Hoch für teilnehmende Domain-Besitzer - Domain-Inhaber müssen alle Pinning-Aufzeichnungen für alle gültigen Zertifiakte aktualisiert auf allen Servers bereit halten, sonst könnte der Zugang zur Webseite blockieren |
Sie haben Fragen? Unser technischer Support steht Ihnen bei weiteren Fragen gerne zur Verfügung!
Copyright 2015 - PSW GROUP - All Rights Reserved
