{"id":1895,"date":"2017-11-20T20:10:14","date_gmt":"2017-11-20T19:10:14","guid":{"rendered":"https:\/\/www.my-it-brain.de\/wordpress\/?p=1895"},"modified":"2020-02-03T11:10:30","modified_gmt":"2020-02-03T09:10:30","slug":"ueber-pinning-hpkp-caa-und-certificate-transparency","status":"publish","type":"post","link":"https:\/\/www.my-it-brain.de\/wordpress\/ueber-pinning-hpkp-caa-und-certificate-transparency\/","title":{"rendered":"\u00dcber Pinning (HPKP), CAA und Certificate Transparency"},"content":{"rendered":"

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

Anschlie\u00dfend werden die vorgestellten Verfahren gegen\u00fcbergestellt und hinsichtlich ihres Nutzens f\u00fcr einen „Subscriber“ und eine „Relying Party“ beurteilt.<\/p>\n

Terminologie<\/h2>\n

F\u00fcr das Verst\u00e4ndnis des Artikels wichtige Begriffe werden in diesem Abschnitt definiert.<\/p>\n

Subscriber<\/strong> stellt eine Entit\u00e4t dar, welche einen gesicherten Service anbieten m\u00f6chte und hierf\u00fcr ein Zertifikat ben\u00f6tigt.<\/p>\n

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

Certificate Pinning (HPKP)<\/h2>\n

Update Februar 2020:<\/strong> HPKP existiert praktisch nicht mehr! <\/strong>Wie im Blog von Scott Helme vom 20.01.2020<\/a> nachzulesen ist, wurde die Unterst\u00fctzung f\u00fcr HPKP [7]<\/a> aus Firefox 72 entfernt. Damit wird HPKP von keinem aktuellen Browser mehr unterst\u00fctzt und ist praktisch tot.<\/p>\n

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.<\/p>\n

Certificate Pinning wurde im RFC 7469 [7]<\/a> spezifiziert. Es handelt sich dabei um einen Mechanismus, bestimmte Eigenschaften eines Zertifikats festzunageln. Der Browser erh\u00e4lt dabei mit dem Zertifikat zus\u00e4tzliche Informationen, mit denen er die Authentizit\u00e4t des Zertifikats \u00fcberpr\u00fcfen kann.<\/p>\n

In der Praxis wird dem Browser ein Hash-Wert \u00fcbermittelt, welcher \u00fcber den \u00f6ffentlichen Schl\u00fcssel des Zertifikats gebildet wurde. Dieser Hash-Wert wird in einem HTTP-Header-Feld an den Browser \u00fcbertragen und von diesem gespeichert. Wie dieses Verfahren genau funktioniert, beschreibt der RFC 7469 ab Abschnitt 2.1.1. Da nur der Dienstbetreiber \u00fcber den dazugeh\u00f6rigen privaten Schl\u00fcssel verf\u00fcgt, ist ein Missbrauch durch Dritte ausgeschlossen. \u00dcbermittelt nun n\u00e4mlich ein Angreifer bei einem MITM-Angriff den zu seinem Zertifikat geh\u00f6renden \u00f6ffentlichen Schl\u00fcssel, kann der Browser mit Hilfe des PINs erkennen, dass dieser Schl\u00fcssel nicht dem Dienstbetreiber geh\u00f6rt und den Angriff damit auffliegen lassen.<\/p>\n

Dem Subscriber steht mit dem Certificate Pinning ein wirksamer Mechanismus zur Verf\u00fcgung, mit dem sich das Risiko, Opfer eines MITM-Angriffs zu werden, deutlich reduzieren l\u00e4sst. Gleichzeitig ist die Implementierung von Pinning in eigene Projekte nicht trivial und das Risiko, den eigenen Internetauftritt durch Fehlkonfiguration f\u00fcr Besucher unerreichbar zu machen, entsprechend hoch (vgl. [1]<\/a>, [2]<\/a>, [6]<\/a> und [7]<\/a>).<\/p>\n

Certification Authority Authorization (CAA)<\/h2>\n

CAA wurde Anfang 2013 im RFC 6844<\/a> spezifiziert. Es handelt sich dabei um einen DNS Ressource Record, mit dem ein Domain-Inhaber festlegen kann, welche Zertifizierungsstellen (CA) f\u00fcr seine Domain Zertifikate ausstellen d\u00fcrfen [4]<\/a>.<\/p>\n

Eine gute Einf\u00fchrung in deutscher Sprache findet sich im DFN-PKI Blog<\/a> in den Artikeln unter [8]<\/a> und [9]<\/a>.<\/p>\n

Die Zertifizierungsstellen wurden vom CA\/Browser-Forum im Ballot 187 [10]<\/a> verpflichtet, sp\u00e4testens ab September 2017 die CAA Resource Records auszuwerten und zu beachten.<\/p>\n

Certificate Transparency (CT)<\/h2>\n

Laut Abstract des RFC 6962<\/a> [5]<\/a> handelt es sich bei Certificate Transparency um ein experimentelles Protokoll zur Buchf\u00fchrung \u00fcber ausgestellte TLS-Zertifikate.<\/p>\n

Die Idee besteht im Wesentlichen darin, dass Zertifizierungsstellen (CA) ausgestellte Zertifikate in ein \u00f6ffentliches (mutma\u00dflich revisionssicheres) Log eintragen. Das Ziel ist, Transparenz bei der Ausstellung von TLS-Zertifikaten herzustellen. So soll jeder Klient einsehen k\u00f6nnen, f\u00fcr welche Domains Zertifikate ausgestellt wurden und welche Zertifizierungsstellen diese ausgestellt haben.<\/p>\n

Durch \u00dcberwachung dieser Certificate Transparency Logs k\u00f6nnen Domain-Inhaber (Subscriber) feststellen, ob TLS-Zertifikate f\u00fcr ihre Domains ausgestellt wurden, ohne dass die Ausstellung von ihnen autorisiert wurde. In diesem Fall k\u00f6nnen sie Schritte einleiten, um diese Zertifikate widerrufen zu lassen. F\u00fcr den Widerruf muss auf bestehende Verfahren zur\u00fcckgegriffen werden, da der Zertifikatswiderruf explizit kein Bestandteil des aktuellen Entwurfs ist.<\/p>\n

Wie stehen diese Verfahren zueinander?<\/h2>\n

Im Kern haben alle drei Verfahren zum Ziel, die gr\u00f6\u00dfte Schwachstelle der Internet-PKI abzudichten. N\u00e4mlich das Problem, dass jede CA Zertifikate f\u00fcr jede beliebige Domain ausstellen darf und eine Relying Party bisher nur schwer erkennen konnte, ob ein vertrauensw\u00fcrdiges Zertifikat tats\u00e4chlich mit Autorisierung des Domain-Inhabers ausgestellt wurde. Dabei verfolgen die drei Verfahren unterschiedliche Ans\u00e4tze.<\/p>\n

Das Certificate Pinning kann vom Subscriber selbst implementiert werden. Er stellt der Relying Party damit Informationen zur Verf\u00fcgung, mit denen diese \u00fcberpr\u00fcfen kann, ob das g\u00fcltige Zertifikat tats\u00e4chlich 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\u00fcr den Subscriber ein wirksames Mittel dar, um das Risiko von Zertifikatsmissbrauch zu reduzieren.<\/p>\n

Doch wo Licht ist, ist auch Schatten. Die Implementierung von Certificate Pinning ist komplex [1]<\/a> und f\u00fchrt bei kleinsten Fehlern bereits zur Nichterreichbarkeit der eigenen Domain. Die Komplexit\u00e4t und das Risiko, die eigene Domain unerreichbar zu machen, sind Gr\u00fcnde, warum das Pinning bisher nur eine sehr geringe Verbreitung erfahren hat. Und damit nicht genug. Kaum in der Welt, wird bereits \u00fcber den Abschied vom HTTP Public Key Pinning diskutiert (vgl. [12]<\/a> und [13]<\/a>) und von einem gro\u00dfen Browserhersteller sogar das Ende der Unterst\u00fctzung eingel\u00e4utet (siehe [14]<\/a> und [15]<\/a>).<\/p>\n

CAA bietet dem Subscriber bzw. Domain-Inhaber \u00fcber DNS-Eintr\u00e4ge die M\u00f6glichkeit, 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]<\/a>, k\u00f6nnen 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]<\/a>. Auch der Subscriber muss sich auf die Selbstverpflichtung der CAs verlassen; kann er doch nicht pr\u00fcfen, ob eine CA ein Zertifikat ohne seine Autorisierung ausgestellt hat.<\/p>\n

Wer sich nun fragt, warum sich eine CA an CAA gebunden f\u00fchlen sollte, dem sei gesagt, dass bei einem Versto\u00df gegen CAA die Entfernung der eigenen Root CA aus dem trust anchor<\/em> der Relying Party droht. So sollte es im eigenen Interesse einer CA liegen, CAA Records gewissenhaft auszuwerten und sich m\u00f6glichst keine Fehler zu erlauben.<\/p>\n

Certificate Transparency bietet einem Subscriber die M\u00f6glichkeit, durch \u00dcberwachung der CT Logs zu erkennen, ob TLS-Zertifikate ohne Autorisierung des Subscribers ausgestellt wurden. Dies setzt nat\u00fcrlich voraus, dass die ausstellende CA diese Zertifikate auch in einem CT Log eintr\u00e4gt. Doch welche Motivation hat eine CA, dies zu tun? Wenn die Browser (Relying Party) mit der gr\u00f6\u00dften Verbreitung zuk\u00fcnftig nur noch Zertifikate als vertrauensw\u00fcrdig einstufen, welche in einem CT Log aufzufinden sind, w\u00e4re dies sicherlich eine Motivation. So k\u00f6nnten die gro\u00dfen Browserhersteller dieser Welt mit ihrer Marktmacht doch eine Transparenz erzwingen.<\/p>\n

Mein pers\u00f6nliches Fazit<\/h2>\n

Als das Public Key Pinning das Licht der Welt erblickte, war ich von dessen M\u00f6glichkeiten begeistert und habe es auch selbst in verschiedenen Umgebungen eingesetzt (siehe [1]<\/a> und [6]<\/a>). Dabei habe ich erkannt, dass der Einsatz mit hohen Risiken verbunden ist und man sich sehr viele Gedanken \u00fcber m\u00f6gliche Auswirkungen in der Zukunft machen muss. Aktuell setze ich in meinen Projekten auf Grund der Risiken kein Pinning mehr ein. Googles Ank\u00fcndigung, die Unterst\u00fctzung aus dem Chrome Browser zu entfernen, klingt wie ein Todessto\u00df f\u00fcr dieses Verfahren. Es bleibt abzuwarten, ob Mozilla mit dem Firefox nachzieht oder das Pinning als Abgrenzungsmerkmal weiter unterst\u00fctzt.<\/p>\n

Insgesamt w\u00fcrde ich mich freuen, wenn man HPKP doch noch retten kann. Denn im Gegensatz zu CAA und CT stellt es f\u00fcr mich die effizienteste und wirksamste Technik dar, um mich selbst und meine Nutzer vor Zertifikatsbetrug sch\u00fctzen zu k\u00f6nnen. 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\u00f6nnen gerade in Kombination dazu beitragen, das Potenzial f\u00fcr Zertifikatsmissbrauch deutlich zu reduzieren.<\/p>\n

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

    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\u00f6chte ich noch einmal kurz in Erinnerung rufen, worum es beim Pinning geht. Dar\u00fcber hinaus finden Sie hier eine kurze Einf\u00fchrung in DNS Certification Authority Authorization (CAA) Resource Records (RFC 6844) [Weiterlesen…]<\/a><\/span><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_metis_text_type":"","_metis_text_length":0,"_post_count":0,"footnotes":""},"categories":[1],"tags":[472,380,473,381,318,417],"class_list":["post-1895","post","type-post","status-publish","format-standard","hentry","category-allgemein","tag-caa","tag-certificate-pinning","tag-certificate-transparency","tag-hpkp","tag-ssl","tag-tls"],"_links":{"self":[{"href":"https:\/\/www.my-it-brain.de\/wordpress\/wp-json\/wp\/v2\/posts\/1895","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.my-it-brain.de\/wordpress\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.my-it-brain.de\/wordpress\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.my-it-brain.de\/wordpress\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.my-it-brain.de\/wordpress\/wp-json\/wp\/v2\/comments?post=1895"}],"version-history":[{"count":20,"href":"https:\/\/www.my-it-brain.de\/wordpress\/wp-json\/wp\/v2\/posts\/1895\/revisions"}],"predecessor-version":[{"id":2336,"href":"https:\/\/www.my-it-brain.de\/wordpress\/wp-json\/wp\/v2\/posts\/1895\/revisions\/2336"}],"wp:attachment":[{"href":"https:\/\/www.my-it-brain.de\/wordpress\/wp-json\/wp\/v2\/media?parent=1895"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.my-it-brain.de\/wordpress\/wp-json\/wp\/v2\/categories?post=1895"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.my-it-brain.de\/wordpress\/wp-json\/wp\/v2\/tags?post=1895"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}