Veraltet: HPKP (HTTP Public Key Pinning) wurde von allen Browsern entfernt. Chrome hat es 2019 abgeschaltet, Firefox 2020. Der Grund: Zu hohes Risiko, sich mit falschen Pins selbst auszusperren. Für Zertifikatsabsicherung nimmt man heute DANE/TLSA und Certificate Transparency.
Die aktuelle Gültigkeitsprüfung anhand von CAs hat so ihre Lücken. So erscheint jedes Zertifikat als gültig und vertrauenswürdig, sofern es nur von einer CA unterzeichnet wurde, welcher der Client selbst vertraut.
Erschleiche ich mir also ein gültiges Zertifikat für eine Domain oder schiebe es dem Client als vertrauenswürdig unter, wird sich der Benutzer zwar sicher und geschützt fühlen, dennoch ist er es nicht.
Mögliche Beispiele finden sich hier:
– Google deckt erneut Missbrauch im SSL-Zertifizierungssystem auf
– Comodo stellt fälschlicherweise Microsoft-Zertifikat aus
Nun gibt es mehrere Ansätze um diese Situation zu verbessern. TLSA / DANE zusammen mit DNSsec, HSTS (Strict Transport Security) usw… Inzwischen bin ich auf fast alle eingegangen. Es fehlt aber noch ein, wie ich finde, wichtiger Vertreter. HPKP (Public Key Pinning). Daher soll es nun um HPKP gehen.
Public Key Pinning verfolgt einen ähnlichen Ansatz, wie Strict Transport Security, erweitert diesen nur etwas. Strict Transport Security wird als HTTP-Header gesetzt und sorgt dafür, dass ein Client für den Ablauf einer, durch diesen Header, gesetzten Frist nur noch SSL/TLS gesicherte Verbindungen zu dieser Domain benutzen wird. Public Key Pinning sorgt nun zusätzlich dafür, dass der Client nur gewisse Zertifikate über einen bestimmten Zeitraum annimmt.
Sind beide Header gesetzt, baut der Client also nur noch gesicherte Verbindungen auf und akzeptiert nur noch bestimmte Zertifikate, für einen gewissen Zeitraum. Dieses bietet ebenfalls gewisse Lücken, dennoch hebt es die Sicherheit ein ganzes Stück an, denn es wird für einen Angreifer deutlich aufwendiger seine gefälschten Zertifikate ins Rennen zu bringen.
Wie funktioniert es nun genau?
Im HPKP Header übermittelt der Webserver zwei base64 encodete SHA256-Hash Werte von den Public Keys zweier Zertifikate, sowie eine Ablaufzeit (und ggf. noch ein paar Optionen). Zwei Hash Werte aus einem einfachen Grund… Es kann ja passieren, dass man sein Zertifikat tauschen möchte/muss. Wäre hier nur der Hash eines Zertifikates „fest gepinnt“, würden alle Clients den Verbindungsaufbau mit dem neuen Zertifikat verweigern und dieses im schlimmsten Fall bis zum Ablauf der gesetzten Frist (in meinem Beispiel gleich 60 Tage). Aus diesem Grund nimmt man zwei! Das aktive Zertifikat, welches man ggf. direkt von der CA unterschreiben lässt und einsetzte, sowie ein Backup-Zertifikat, welches man vielleicht nur bis zum CSR vorbereitet und an einer anderen Stelle aufbewahrt. Nun könnte man direkt noch ein anderes Verfahren einsetzten oder ein anderes System um dieses Zertifikat zu erzeugen usw. usw… Wir halten also fest, Hash Werte von zwei Zertifikaten, wobei eines selbstverständlich das aktive ist.
Diese Hashwerte lassen sich nun mittels openssl über die keys, csr oder das fertige Zertifikat bauen. Ich nehme dafür gerne direkt die keys, da sich aus diesen alles weitere ergibt. Als Test, auf korrekte Hash Werte, kann man natürlich alle drei Wege nutzen. Dabei sollten sich natürlich immer die gleichen Werte ergeben!
Ich gehe also davon aus, dass bereits zwei Keys erstellt wurden. Damit lassen sich nun wie folgt die Hash Werte erstellen:
$ openssl pkey -in http-active.key -pubout | grep -v PUBLIC|base64 -d|openssl dgst -sha256 -binary|base64
31XofAyJSqWKGO4xhVZFNe5+grAZQ4cvl2tahddU/ME=
$ openssl pkey -in http-backup.key -pubout | grep -v PUBLIC|base64 -d|openssl dgst -sha256 -binary|base64
KJV9jpFftvj+TjzaVtnI44aYm8DdjdO00vFZ+YtBjdA=
Um die Header setzten zu können muss beim Apache noch das Modul headers geladen werden:
$ a2enmod headers
In der eigentlichen Konfigurationsdatei des jeweiligen hosts/vhosts fehlt nun nur noch folgende Zeile:
Header always set Public-Key-Pins: 'max-age=5184000; pin-sha256="31XofAyJSqWKGO4xhVZFNe5+grAZQ4cvl2tahddU/ME="; pin-sha256="KJV9jpFftvj+TjzaVtnI44aYm8DdjdO00vFZ+YtBjdA="'
Hash Werte natürlich einpassen. und in dem Zuge über HSTS nachdenken!
Zusätzlich können noch ein paar Optionen in diesem Header folgen. So zum Beispiel report-uri=”http://www.example.org/hpkpReportUrl” Hier wird über einen HTTP-Post einige Informationen vom Client im JSON Format übertragen. Also ob es Probleme gab oder nicht… Die dort folgende URL sollte demnach vielleicht nicht SSL/TLS gesichert sein, oder nicht unter der gleichen Domain liegen. Wäre im Fehlerfall ja sonst ebenfalls nicht erreichbar! Ebenfalls lässt sich mittels includeSubdomains; zusätzlich angeben, dass dieses ebenso für alle Subdomains gilt.
Prüfen?
Prüfen kann man alles natürlich wieder per https://www.ssllabs.com/
Viel Spaß und wie immer, bei Fragen; fragen!
DNSSEC und DNS-based Authentication of Named Entities (DANE)
Apache und sichere SSL / TLS Verschlüsselung
Über Sinn und Unsinn kann man sich nun streiten. Ändert aber nichts, da Google dieses einfach in ihren Browser fest eingebaut hat. Möchte man nun also kein gelbes Ausrufezeichen in der Adresszeile vom Chrome haben, muss die eigene CA CT unterstützen und das Zertifikat veröffentlichen.
StartSSL/StartCOM tut dieses bisher noch nicht. Ich habe aber folgende Info bekommen:
There will be support shortly for submitting to the CT logs and installing the response for CT aware web servers (TLS extension). Support for the latter is lacking for a large part, but it should get better over time, most likely Apache first.
Wenn ich mehr habe, gibt es mehr.
In diesem Sinne….
