Schlagwort-Archive: HPKP

Über Pinning (HPKP), CAA und Certificate Transparency

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

Mein TLS/SSL-Kochbuch

Heutzutage werden immer mehr Kommunikationsverbindungen im Internet mit TLS/SSL-Verbindungen geschützt. Die Verschlüsselung hilft, die Vertraulichkeit der zwischen Sender und Empfänger übertragenen Daten zu schützen und sollte daher standardmäßig aktiviert sein. Doch bereitet der Einsatz von TLS/SSL-Verschlüsselung noch immer vielen Administratoren und Betreibern verschiedenster Anwendungen Kopfschmerzen. Zu undurchsichtig scheint der Dschungel aus Zertifizierungsstellen, Zertifikaten, Zertifikatsanfragen, öffentlichen und privaten Schlüsseln zu sein. Verschiedenste Validierungsverfahren und Dateiformate für Zertifikate tragen nicht gerade dazu bei, den Durchblick zu behalten. Bereits die Erstellung einer Zertifikatsanfrage gerät dabei häufig genug zu einem Problem. Die richtige Konfiguration der zu sichernden Server bzw. Dienste erscheint kompliziert und Fehler in der Konfiguration führen nicht selten zur Nichterreichbarkeit einer Webseite. Die Folge: Immer noch wird viel zu häufig auf den Einsatz von TLS/SSL-Verschlüsselung verzichtet.

Mit meinem TLS-Kochbuch möchte ich dazu beitragen, etwas Licht ins Dunkel zu bringen. Darin finden sich Rezepte mit praktischen Tipps für die Verwendung von TLS/SSL-Verschlüsselung mittels OpenSSL, HTTP Strict Transport Security (HSTS) und HTTP Public Key Pinning (HPKP).

Aus dem Inhalt

Nach der Einleitung führt Kapitel 2 in das Thema ein und definiert die wesentlichen Begriffe. Es bildet die Grundlage für das Verständnis der daran anschießenden Kapitel.

In Kapitel 3 geht es um die Implementierung von TLS/SSL. Hier werden verschiedene Methoden zur Generierung von privaten Schlüsseln und Certificate Signing Requests vorgestellt. Darüber hinaus werden einige Zertifizierungsstellen kurz vorgestellt, bei denen Zertifikate beantragt werden können. Im Folgenden wird auf die Implementierung von TLS/SSL-Zertifikaten in verschiedenen Diensten eingegangen. Hier wird insbesondere die Implementierung von Zertifikaten der recht jungen Zertifizierungsstelle „Let’s Encrypt“ erläutert, mit deren Hilfe sich der Prozess der Zertifikatserneuerung automatisieren lässt.

Der Implementierung des HTTP Public Key Pinning (HPKP) widmet sich Kapitel 4. Das Pinning-Verfahren wird am Beispiel des Webservers NGINX erläutert und getestet.

Zum Schluss werden die in den einzelnen Kapiteln vorgestellten Techniken und Methoden nochmals zusammenfassend an einem konkreten Beispiel in Kapitel 5 verdeutlicht.

Hier geht es zum Text

Mir persönlich hat die Arbeit an folgendem Dokument geholfen, mich detailliert mit der Thematik auseinanderzusetzen und mein Wissen zu erweitern und zu vertiefen. Ich freue mich, wenn mein Kochbuch auch euch dabei hilft, ein besseres Verständnis für das Thema zu entwickeln.

Dies ist die erste Ausgabe meines TLS/SSL-Kochbuchs und es gibt sicher noch viel mehr, was man zu diesem Thema schreiben kann. Fehler sowie Wünsche zum Inhalt zukünftiger Ausgaben können gern an die E-Mail-Adresse tls-rezepte(aet)my-it-brain(Punkt)de gemeldet werden.

Downloads zum Text

Erster bekannter Missbrauch eines Let’s Encrypt Zertifikats

Dennis Schirrmacher berichtet in seinem heise-Artikel „Erste Malvertising-Kampagne mit Let’s-Encrypt-Zertifikat“ über die missbräuchliche Verwendung eines Let’s Encrypt Zertifikats.

Laut dem Artikel ist es Online-Gaunern gelungen, eine Subdomain für eine legitime Domain einzurichten und für diese ein Let’s Encrypt Zertifikat zu beantragen. Mit Hilfe der legitimen Domain und des vertrauenswürdigen Zertifikats wird Besuchern der Webseite Schadcode untergeschoben. Im konkreten Fall wird ein Online-Banking-Trojaner auf den Computern der Opfer installiert.

Die missbräuchliche Nutzung ist kein spezielles Problem von Let’s Encrypt. Es handelt sich vielmehr um ein generelles Designproblem der öffentlichen TLS/SSL-Infrastruktur, welches ich bereits in der Einleitung von „Certificate Pinning mit NGINX“ beschrieben habe.

Let’s Encrypt versucht den Missbrauch durch den Einsatz kurzlebiger Zertifikate einzuschränken. Dieser Versuch läuft meiner Ansicht nach jedoch weitgehend ins Leere. Denn auch Online-Gauner können die Erneuerung der ergaunerten Zertifikate mit dem Let’s Encrypt Client automatisieren.

Einen deutlich effektiveren Schutz gegen die genannte Art von Missbrauch bieten Verfahren wie „Public Key Pinning Extension for HTTP“[1. RFC 7469 – Public Key Pinning Extension for HTTP] [2. HTTP Public Key Pinning – Wikipedia (de)] und „HTTP Strict Transport Security (HSTS)“[3. RFC 6796 – HTTP Strict Transport Security (HSTS)] [4. HTTP Strict Transport Security – Wikipedia (de)]. Speziell mit Hilfe des Certificate Pinning kann ein Browser erkennen, ob ein TLS/SSL-Zertifikat zur besuchten Domain gehört oder nicht. Nähere Informationen dazu und wie das Certificate Pinning für den Webserver NGINX konfiguriert werden kann, finden sich im Artikel „Certificate Pinning mit NGINX“. Viel Spaß beim Lesen.