Http Public Key Pinning (HPKP) und der von Google veranlasste Zertifikatswechsel von Symantec zu DigiCert - Certificate Transparency (CT) erst ab April 2018

12.01.2018 23:48:32, Jürgen Auer, keine Kommentare

Leser des hiesigen Blogs und Kunden sowie Nutzer von Server-Daten wissen, daß alle Zugriffe unter server-daten.de verschlüsselt sind.

Da mag man vielleicht denken: "Einmal ein Zertifikat drauf, das reicht für zehn Jahre". Praktisch ist die Geschichte ab und zu "deutlich aufwendiger".

So nutze ich hier (aktuell Januar 2018) ein Sternzertifikat von RapidSSL. Das gilt damit für alle Subdomains unter server-daten.de, also für www.server-daten.de ebenso wie für alle Kundendatenbanken der Form datenbankname.server-daten.de. Das hat u.a. den Vorteil, daß zu einem neuen Kunden eine neue Datenbank und eine neue Subdomain gehört, das vorhandene Zertifikat aber weiterverwendet werden kann.

Ferner ist das Zertifikat "gepinnt": Das war bis jetzt ein Http-Header, der zu jeder Seite mitgeschickt wurde und die folgende Struktur hatte:

> Public-Key-Pins: max-age=2592000; pin-sha256="h6801m+z8v3zbgkRHpq6L29Esgfzhj89C1SyUCOQmqU="; pin-sha256="Vjs8r4z+80wjNcr1YKepWQboSIRi63WsWXhIMN+eWys="; includeSubDomains

Das bedeutet: Der erste pin-sha256-Wert ist der SHA256-Wert des "GeoTrust Global CA" - Root-Zertifikats. Das finden Sie auch bsp. in Ihrem FireFox-Browser in der Rubrik "Datenschutz & Sicherheit" - "Zertifikate" - "Zertifikate anzeigen". Dieses Zertifikat hatte ein Zertifikat von RapidSSL signiert. Letzteres hat das Sternzertifikat der hiesigen Domain signiert. Der zweite pin-sha256-Wert ist der Wert für das "DST Root CA X3" Zertifikat. Das dient u.a. Letsencrypt als Basis.

Http Public Key Pinning (HPKP) bedeutet nun, daß einer dieser pin-sha256-Werte in der Zertifikatskette des hiesigen Zertifikats auftauchen muß. Die anderen Werte dürfen nicht in der Zertifikatskette auftauchen. Das sind Backup-Keys, die dazu dienen, bei einem Wechsel des Zertifikats die neue Zertifikatskette zu pinnen.

Würde also eine Certificate Authority (CA), ein Unternehmen, das Zertifikate ausstellt, mit einem eigenen Root-Zertifikat ein Zertifikat von *.server-daten.de signieren und hätte der Nutzer innerhalb der 30 Tage zuvor (30 Tage * 24 Stunden * 3600 Sekunden pro Stunde = 2592000 Sekunden) die hiesige, "richtige Domain" aufgerufen, dann würde der Browser die Verbindung zu dieser anderen Domain verweigern. Eben weil kein SHA256-Wert aus der Zertifikatskette in dem obigen Header enthalten ist und weil sich der Browser diese Information 30 Tage lang merken soll, bis sie ungültig wird.

Theoretisch ist das ein interessantes Konzept. Praktisch kann es zu unerwarteten Problemen führen und ernsthafte Sicherheitsprobleme für unerfahrene Website-Betreiber produzieren. Google hat das Konzept eine Weile forciert, will sich in Kürze aber wieder davon verabschieden.

Nun hatte sich Google mit Symantec überworfen. Bei Symantec hatten Mitarbeiter 2015 Zertifikate für Google-Domains ausgestellt, ohne daß Google diese beantragt hatte. Solche Zertifikate lassen sich bsp. für Man-in-the-middle-Angriffe verwenden: Nutzer denken, sie greifen auf Google zu. In Wirklichkeit ist das die Domain eines Hackers. Dann stellte sich heraus, daß es in den Certificate-Transparency-Logs, in denen ausgestellte Zertifikate protokolliert werden, Zertifikate von Symantec gab, welche die Domaininhaber nie beantragt hatten. Schließlich war die Rede von etwa 30.000 Zertifikaten, die zweifelhaft waren.

Ergebnis war schließlich, daß Google EV-Zertifikate von Symantec nicht mehr anerkennen wollte. Ferner sollte die Laufzeit der Zertifikate deutlich verkürzt werden. Im letzten Jahr hatte Google schließlich das Aus verkündet:

Chrome’s Plan to Distrust Symantec Certificates

https://security.googleblog.com/2017/09/chromes-plan-to-distrust-symantec.html

Aus Chrome sollten alle Root-Zertifikate entfernt werden, die von Symantec stammen. Das Problem dabei: Symantec hat diverse Tochterunternehmen, die dieselbe Infrastruktur nutzen: Thawte, Equifax, Geotrust, Verisign - an Geotrust hängt RapidSSL und damit die hiesige Domain. Laut Berichten war Symantec zeitweilig für 42 Prozent aller aktiven SSL-Zertifikate verantwortlich.

Google legte fest: Ab Chrome 66 wird allen Zertifikaten nicht mehr vertraut, die von der Symantec-Infrastruktur stammen und die vor dem 01.06.2016 ausgestellt wurden. Ab diesem Zeitpunkt hatte Symantec an der Certificate Transparency teilgenommen. Damit wurden ab diesem Zeitpunkt alle signierten Zertifikate in öffentlich zugängliche und schreibgeschützte Logdateien eingetragen. Das ermöglicht eine Kontrolle darüber, welche Zertifikate zu einer Domain existieren. Die Chrome-Version 66 soll am 17.04.2018 veröffentlicht werden.

Ab Chrome 70 soll die Symantec-Infrastruktur komplett aus Chrome entfernt werden. Wirkung: Chrome würde bei allen Zertifikaten, die von dieser Infrastruktur signiert worden sind, eine Warnmeldung anzeigen und keine Verbindung mehr herstellen. Chrome 70 soll um den 23.10.2018 veröffentlicht werden. Folgerung: Das hiesige Zertifikat ermöglicht zwar technisch eine sichere Verschlüsselung und ist bis August 2019 gültig. Entziehen aber Google und andere Browserhersteller das Vertrauen, ist die hiesige Domain nicht mehr per Chrome aufrufbar. Mozilla möchte sich diesem Schritt anschließen, so daß auch mit FireFox die Domain nicht mehr nutzbar wäre.

Die Konsequenz dieser Google-Maßnahme: Alle Websites mit Zertifikaten aus dieser Infrastruktur brauchen neue Zertifikate basierend auf Root-Zertifikaten, denen Google vertraut.

Schließlich hat Symantec Ende letzten Jahres die gesamte Zertifikatssparte an DigiCert verkauft. Die gesamte Zertifikatsinfrastruktur von Symantec fliegt raus und wird durch jene von DigiCert ersetzt.

Die Konsequenz: DigiCert bietet nun allen bisherigen Nutzern der Symantec-Infrastruktur einen Zertifikatsaustausch an. Das geht direkt über die Tochterfirmen, die alle weiter existieren.

Soweit der Hintergrund. Gestern erhielt ich eine Mail, daß ich das Zertifikat für Server-Daten aus diesen Gründen austauschen könne. Ok, ein neues beantragt, das dasselbe Laufzeitende hat wie das bisherige Zertifikat. Den Link in der Mail bestätigt, dann kam das Zertifikat. Das wurde zusammen mit dem Zwischenzertifikat eingespielt, im Testsystem aktiviert.

Und dann? Dann funktionierte gar nichts. Grund: Die Http Public Key Pinning - Definition verweigerte die Verbindung. Klar. Das war ein neues Root-Zertifikat, mit dem ein neues RapidSSL-Zwischenzertifikat signiert worden war. Das hatte mein neues Zertifikat signiert. Damit fehlte ein passender pin-sha256-Wert im Header.

Positiv formuliert: Die Http Public Key Pinning - Logik funktionierte im FireFox wie gewünscht.

Folglich den Header geändert:

> Public-Key-Pins: max-age=3600; pin-sha256="h6801m+z8v3zbgkRHpq6L29Esgfzhj89C1SyUCOQmqU="; pin-sha256="nKWcsYrc+y5I8vLf1VGByjbt+Hnasjl+9h8lNKJytoE="; pin-sha256="Vjs8r4z+80wjNcr1YKepWQboSIRi63WsWXhIMN+eWys="; includeSubDomains

Die Zeit auf eine Stunde runtergesetzt. Einen weiteren pin-sha256 ergänzt - nämlich den vom neuen Zwischenzertifikat. Auf dem Testsystem nochmals das alte Zertifikat aktiviert. Einmal per FireFox drauf zugegriffen, damit dieser den neuen Hashwert cachen konnte. Und prompt konnte ich nun im Testsystem auch das neue Zertifikat nutzen.

Inzwischen läuft der neue Header auf dem Hauptsystem. Da muß ich nun 30 Tage warten, um sicher sein zu können, daß kein Browser mehr die alten, lediglich zwei pin-sha256-Werte gecacht hat. Nach 30 Tagen verfallen die alten Werte. Damit blockiert das nicht mehr.

Mit anderen Worten: Wenn man aufgrund eines solchen Konflikts zwischen Google und Symantec plötzlich und ungeplant ein neues Zertifikat braucht: Wer da HPKP nicht verwendet, der hat es einfach. Dann würde das neue Zertifikat schon längst laufen. Rein und fertig. Wer diesen erweiterten Schutz nutzt, muß eventuell sehr viel mehr Zeit einplanen. Und hätte ich den Zeitraum auf ein Jahr gesetzt, dann hätte ich mir damit bereits richtige Probleme produzieren können. Der eine Monat ist noch zu verkraften.

Allerdings: Vorhin spiele ich etwas rum. Und stelle etwas entgeistert fest, daß das neue Zertifikat gar nicht per Certificate Transparency auffindbar ist. Da gibt es Seiten zum Suchen:

https://crt.sh/

und

https://transparencyreport.google.com/https/certificates

Da waren die letzten Einträge für server-daten.de von 2016. Schließlich stellte sich heraus:

Google CT to Expand to All Certificates Types

https://www.digicert.com/blog/google-certificate-transparency-expand-to-all-certificate-types/

DigiCert nutzt aktuell Certificate Transparency nur für Extended Validation (EV) - Zertifikate. Nicht aber für die "einfacheren Varianten" Domain Validated (DV) und Organization Validated (OV) - Zertifikate. Erst ab April 2018 will DigiCert alle signierten Zertifikate per Certificate Transparency veröffentlichen.

Die Konsequenz: Wenn ich das Zertifikat, das aktuell auf dem Testsystem liegt, in einem Monat auf dem Hauptsystem aktiviere, verliere ich die öffentliche Kennzeichnung als CT-Zertifikat. Also werde ich wohl bis April warten. Und mir dann erneut ein neues Zertifikat für die verbleibende Restlaufzeit ausstellen lassen. Dann mit CT - und hoffentlich mit demselben Zwischenzertifikat, das aktuell per HPKP als PIN markiert ist. Sollte das neue Zertifikat mit einem neuen Zwischenzertifikat signiert werden, das nicht in meiner Zertifikatskette drin hängt: Dann muß ich nur noch eine Stunde warten, bis ich das aktualisieren kann.

Wer also ebenfalls ein Symantec-Zertifikat hat, das nach dem 01.06.2016 ausgestellt wurde und wer nun über den gleichen Dienstleister das Angebot erhält, sein Zertifikat durch eines zu ersetzen, das von der DigiCert-Infrastruktur signiert wurde: Der sollte prüfen, ob er nicht lieber noch drei Monate wartet. Um die Certificate Transparency nicht zu verlieren.

Zum Testen kann man übrigens

https://report-uri.com/home/pkp_analyse

nutzen. Bei den dortigen Tools gibt es auch die Möglichkeit, direkt einen öffentlichen Schlüssel eines Zertifikats hochzuladen und sich davon den für Http Public Key Pinning benötigten pin-sha256 - Wert anzeigen zu lassen. Darüber hatte ich den pin-sha256-Eintrag für das neue Zwischenzertifikat erhalten.

Fazit: Die Sicherheit von SSL-Zertifikaten ist eine "komplexe Geschichte". Die Certificate Authority (CA) - Unternehmen sowie die Browserhersteller haben eine große Verantwortung gegenüber den Website-Betreibern und gegenüber den Nutzern dieser Websites.

Update 21.01.2018: Gestern, am 20.01.2018, stellte sich heraus, daß das neue Zertifikat nun per

https://crt.sh/

auffindbar war. Es wurde am 19.01.2018 von https://ct.googleapis.com/logs/argon2019 geloggt. Nach der Ausstellung am 11.01.2018 hat es also noch 8 Tage gedauert, bis das Zertifikat zum ersten Mal in einem Log aufgetaucht ist. Eigentlich sollte das ja sofort bzw. noch vor der Ausstellung der Fall sein. In diesen acht Tagen hätte ein nicht autorisierter Nutzer schon viel Schaden anrichten können.

*
* (wird nicht angezeigt)
Die Erläuterungen zum Datenschutz habe ich gelesen und stimme diesen zu.