In der Vergangenheit habe ich mich auf diesem Blog bereits in verschiedenen Artikeln mit dem Thema Certificate Pinning befasst [vgl. 1-3]. Im vorliegenden Artikel möchte ich noch einmal kurz in Erinnerung rufen, worum es beim Pinning geht. Darüber hinaus finden Sie hier eine kurze Einführung in DNS Certification Authority Authorization (CAA) Resource Records (RFC 6844) [4] und Certificate Transparency (RFC 6962) [5].

Anschließend werden die vorgestellten Verfahren gegenübergestellt und hinsichtlich ihres Nutzens für einen „Subscriber“ und eine „Relying Party“ beurteilt.

Terminologie

Für das Verständnis des Artikels wichtige Begriffe werden in diesem Abschnitt definiert.

Subscriber stellt eine Entität dar, welche einen gesicherten Service anbieten möchte und hierfür ein Zertifikat benötigt.

Die Relying Party bezeichnet z.B. Webbrowser oder andere Programme, welche Zertifikate nutzen und versuchen, deren Echtheit zu validieren. Dies geschieht mit Hilfe von sogenannten trust anchors, also Zertifikaten, denen ultimativ vertraut wird und die in den Webbrowsern gespeichert sind.

Certificate Pinning (HPKP)

Update Februar 2020: HPKP existiert praktisch nicht mehr! Wie im Blog von Scott Helme vom 20.01.2020 nachzulesen ist, wurde die Unterstützung für HPKP [7] aus Firefox 72 entfernt. Damit wird HPKP von keinem aktuellen Browser mehr unterstützt und ist praktisch tot.

Ich lasse diesen Abschnitt zum Gedenken an diesen Mechanismus stehen. Die ebenfalls in diesem Artikel beschriebenen Verfahren CAA und Certificate Transparency gewinnen hingegen durch den Wegfall von HPKP weiter an Bedeutung.

Certificate Pinning wurde im RFC 7469 [7] spezifiziert. Es handelt sich dabei um einen Mechanismus, bestimmte Eigenschaften eines Zertifikats festzunageln. Der Browser erhält dabei mit dem Zertifikat zusätzliche Informationen, mit denen er die Authentizität des Zertifikats überprüfen kann.

In der Praxis wird dem Browser ein Hash-Wert übermittelt, welcher über den öffentlichen Schlüssel des Zertifikats gebildet wurde. Dieser Hash-Wert wird in einem HTTP-Header-Feld an den Browser übertragen und von diesem gespeichert. Wie dieses Verfahren genau funktioniert, beschreibt der RFC 7469 ab Abschnitt 2.1.1. Da nur der Dienstbetreiber über den dazugehörigen privaten Schlüssel verfügt, ist ein Missbrauch durch Dritte ausgeschlossen. Übermittelt nun nämlich ein Angreifer bei einem MITM-Angriff den zu seinem Zertifikat gehörenden öffentlichen Schlüssel, kann der Browser mit Hilfe des PINs erkennen, dass dieser Schlüssel nicht dem Dienstbetreiber gehört und den Angriff damit auffliegen lassen.

Dem Subscriber steht mit dem Certificate Pinning ein wirksamer Mechanismus zur Verfügung, mit dem sich das Risiko, Opfer eines MITM-Angriffs zu werden, deutlich reduzieren lässt. Gleichzeitig ist die Implementierung von Pinning in eigene Projekte nicht trivial und das Risiko, den eigenen Internetauftritt durch Fehlkonfiguration für Besucher unerreichbar zu machen, entsprechend hoch (vgl. [1], [2], [6] und [7]).

Certification Authority Authorization (CAA)

CAA wurde Anfang 2013 im RFC 6844 spezifiziert. Es handelt sich dabei um einen DNS Ressource Record, mit dem ein Domain-Inhaber festlegen kann, welche Zertifizierungsstellen (CA) für seine Domain Zertifikate ausstellen dürfen [4].

Eine gute Einführung in deutscher Sprache findet sich im DFN-PKI Blog in den Artikeln unter [8] und [9].

Die Zertifizierungsstellen wurden vom CA/Browser-Forum im Ballot 187 [10] verpflichtet, spätestens ab September 2017 die CAA Resource Records auszuwerten und zu beachten.

Certificate Transparency (CT)

Laut Abstract des RFC 6962 [5] handelt es sich bei Certificate Transparency um ein experimentelles Protokoll zur Buchführung über ausgestellte TLS-Zertifikate.

Die Idee besteht im Wesentlichen darin, dass Zertifizierungsstellen (CA) ausgestellte Zertifikate in ein öffentliches (mutmaßlich revisionssicheres) Log eintragen. Das Ziel ist, Transparenz bei der Ausstellung von TLS-Zertifikaten herzustellen. So soll jeder Klient einsehen können, für welche Domains Zertifikate ausgestellt wurden und welche Zertifizierungsstellen diese ausgestellt haben.

Durch Überwachung dieser Certificate Transparency Logs können Domain-Inhaber (Subscriber) feststellen, ob TLS-Zertifikate für ihre Domains ausgestellt wurden, ohne dass die Ausstellung von ihnen autorisiert wurde. In diesem Fall können sie Schritte einleiten, um diese Zertifikate widerrufen zu lassen. Für den Widerruf muss auf bestehende Verfahren zurückgegriffen werden, da der Zertifikatswiderruf explizit kein Bestandteil des aktuellen Entwurfs ist.

Wie stehen diese Verfahren zueinander?

Im Kern haben alle drei Verfahren zum Ziel, die größte Schwachstelle der Internet-PKI abzudichten. Nämlich das Problem, dass jede CA Zertifikate für jede beliebige Domain ausstellen darf und eine Relying Party bisher nur schwer erkennen konnte, ob ein vertrauenswürdiges Zertifikat tatsächlich mit Autorisierung des Domain-Inhabers ausgestellt wurde. Dabei verfolgen die drei Verfahren unterschiedliche Ansätze.

Das Certificate Pinning kann vom Subscriber selbst implementiert werden. Er stellt der Relying Party damit Informationen zur Verfügung, mit denen diese überprüfen kann, ob das gültige Zertifikat tatsächlich vom Subscriber bzw. einer von ihm autorisierten CA stammt. Liefert die Validierung eines PINs ein negatives Ergebnis, wird ein Zugriff auf die entsprechende Webseite durch den Webbrowser verweigert. Pinning stellt für den Subscriber ein wirksames Mittel dar, um das Risiko von Zertifikatsmissbrauch zu reduzieren.

Doch wo Licht ist, ist auch Schatten. Die Implementierung von Certificate Pinning ist komplex [1] und führt bei kleinsten Fehlern bereits zur Nichterreichbarkeit der eigenen Domain. Die Komplexität und das Risiko, die eigene Domain unerreichbar zu machen, sind Gründe, warum das Pinning bisher nur eine sehr geringe Verbreitung erfahren hat. Und damit nicht genug. Kaum in der Welt, wird bereits über den Abschied vom HTTP Public Key Pinning diskutiert (vgl. [12] und [13]) und von einem großen Browserhersteller sogar das Ende der Unterstützung eingeläutet (siehe [14] und [15]).

CAA bietet dem Subscriber bzw. Domain-Inhaber über DNS-Einträge die Möglichkeit, CAs zur Ausstellung von Zertifikaten zu autorisieren. Dieser Schutz wirkt passiv, da er darauf basiert, dass sich die CAs an die Verpflichtung aus [10] halten. Schert sich eine CA nicht um diese Verpflichtung, wird durch staatliche Stellen zur Ausstellung von Zertifikaten gezwungen oder durch Einbruch kompromittiert [6, Abschnitt 2.5], können weiterhin Zertifikate ausgestellt werden, denen die Relying Party vertraut. Da eine Nutzung von CAA durch die Relying Party zum Zweck der Zertifikatsvalidierung explizit ausgeschlossen ist [8]. Auch der Subscriber muss sich auf die Selbstverpflichtung der CAs verlassen; kann er doch nicht prüfen, ob eine CA ein Zertifikat ohne seine Autorisierung ausgestellt hat.

Wer sich nun fragt, warum sich eine CA an CAA gebunden fühlen sollte, dem sei gesagt, dass bei einem Verstoß gegen CAA die Entfernung der eigenen Root CA aus dem trust anchor der Relying Party droht. So sollte es im eigenen Interesse einer CA liegen, CAA Records gewissenhaft auszuwerten und sich möglichst keine Fehler zu erlauben.

Certificate Transparency bietet einem Subscriber die Möglichkeit, durch Überwachung der CT Logs zu erkennen, ob TLS-Zertifikate ohne Autorisierung des Subscribers ausgestellt wurden. Dies setzt natürlich voraus, dass die ausstellende CA diese Zertifikate auch in einem CT Log einträgt. Doch welche Motivation hat eine CA, dies zu tun? Wenn die Browser (Relying Party) mit der größten Verbreitung zukünftig nur noch Zertifikate als vertrauenswürdig einstufen, welche in einem CT Log aufzufinden sind, wäre dies sicherlich eine Motivation. So könnten die großen Browserhersteller dieser Welt mit ihrer Marktmacht doch eine Transparenz erzwingen.

Mein persönliches Fazit

Als das Public Key Pinning das Licht der Welt erblickte, war ich von dessen Möglichkeiten begeistert und habe es auch selbst in verschiedenen Umgebungen eingesetzt (siehe [1] und [6]). Dabei habe ich erkannt, dass der Einsatz mit hohen Risiken verbunden ist und man sich sehr viele Gedanken über mögliche Auswirkungen in der Zukunft machen muss. Aktuell setze ich in meinen Projekten auf Grund der Risiken kein Pinning mehr ein. Googles Ankündigung, die Unterstützung aus dem Chrome Browser zu entfernen, klingt wie ein Todesstoß für dieses Verfahren. Es bleibt abzuwarten, ob Mozilla mit dem Firefox nachzieht oder das Pinning als Abgrenzungsmerkmal weiter unterstützt.

Insgesamt würde ich mich freuen, wenn man HPKP doch noch retten kann. Denn im Gegensatz zu CAA und CT stellt es für mich die effizienteste und wirksamste Technik dar, um mich selbst und meine Nutzer vor Zertifikatsbetrug schützen zu können. Dies sage ich, ohne CAA und CT damit abwerten zu wollen. Auch diese beiden Verfahren tragen dazu bei, die Schwachstelle im Design der Internet-PKI zu verkleinern und sie können gerade in Kombination dazu beitragen, das Potenzial für Zertifikatsmissbrauch deutlich zu reduzieren.

Quellen und weiterführende Links

1. Certificate Pinning mit NGINX
2. Pinning-Test im Firefox bei lokaler Root-CA erzwingen
3. Mein TLS/SSL-Kochbuch
4. DNS Certification Authority Authorization (CAA) Resource Record – RFC 6844 {en}
5. Certificate Transparency – RFC 6962 {en}
6. TLS-Kochbuch – Rezepte für die Verwendung von OpenSSL, HTTP Strict Transport Security (HSTS) und HTTP Public Key Pinning (HPKP)
7. Public Key Pinning Extension for HTTP – RFC 7469 {en}
8. RFC 6844 Certification Authority Authound Folgenrization (CAA)
9. CAA RRs – Reihenfolge im DNS
10. Ballot 187 – Make CAA Checking Mandatory {en}
11. http://www.certificate-transparency.org/ {en}
12. Ivan Ristic Is HTTP Public Key Pinning Dead? {en}
13. Scott Helme: I’m giving up on HPKP {en}
14. Scott Helme: The death knell for HPKP? {en}
15. heise Security: HTTPS-Verschlüsselung: Google verabschiedet sich vom Pinning