Name Constraints in X509 Zertifikaten

vorhergehende Artikel in: PKI-X.509-CA Security
17.10.2016

Ich wollte im Zuge der Untersuchungen zur Einrichtung einer CA/PKI die Auswirkungen von Name Constraints untersuchen - Hier die Ergebnisse:

Warum?

Name Constraints sind Erweiterungen von x509v3-Zertifikaten, die nur in CA-Zertifikaten Sinn machen (vergleiche RFC 2459 Punkt 4.2.1.11 oder RFC 5280 Punkt 4.2.1.10): Mit ihnen kann man steuern, welche Zertifikate eine CA ausstellen darf und welche nicht. Das erscheint vielleicht -speziell im Fall von OpenSSL - redundant, da man ja bereits für die Felder des Requests Einschränkungen anlegen kann. Diese sind aber zu nichts nütze, wenn einem Angreifer der private Schlüssel besagter CA in die Hände fällt: In diesem Fall schreibt sich der Angreifer einfach eine eigene Konfiguration, in der die Einschränkungen fehlen und kann wieder Zertifikate für Hinz, Kunz und Google ausstellen.

Das war in der Tat auch der Grund für diese Untersuchungen meinerseits: Dass in den vergangenen Jahren immer wieder Zertifikate für wohlbekannte Dienste auftauchten, die mit gestohlenenen CA-Schlüsseln signiert waren. Prüft ein Client nur die Validität des Zertifikats und die Vertrauenswürdigkeit des Ausstellers, winkt er ein Zertifikat für www.google.com durch, obwohl (Beispiel!!) es höchst unwahrscheinlich ist, dass etwa die Telekom Deutschland gefragt wird, wenn Google ein neues Zertifikat braucht.

Die Lösung für so etwas ist zur Zeit Certificate Pinning. Aber ich habe mich gefragt: gibt es dafür nicht bereits eine Lösung und ist das wieder einmal ein Fall, wo bestehende Technologie einfach nur falsch eingesetzt wird? Ist also nicht die Technik schuld, sondern die Menschen, die damit nicht umzugehen wissen?

Meiner Ansicht nach ist exakt das der Fall: würden in allen CA-Zertifikaten immer ordentlich die Name-Constraints gepflegt und würden die Clients die Einhaltung prüfen, würden solche Fälle wie der eben beschriebene hypothetische unmöglich werden. Es würde dazu bereits ausreichen, einen DNS- oder URI-Constraint im Telekom-Zertifikat zu verankern, der aussagt, dass die CA nur für Server ausstellen darf, deren Domain-Name mit ".de" endet. Hätte der Client dann dies ordentlich geprüft, wäre die Manipulation aufgeflogen.

Ich wollte nun testen, inwieweit man heute durch solche Maßnahmen geschützt wird. Dazu stellte ich folgende Fragen:

  • Wie verbreitet ist es?
  • Wird durch eine Verletzung des Name-Cnostraints das Ausstellen eines Zertifikats verhindert?
  • Falls nicht - checken Clients die Name-Constraints und handeln sie entsprechend?

Wie verbreitet ist es?

Leider findet man kaum Zertifikate in freier Wildbahn, die tatsächlich Name-Constraints enthalten. Ich habe dafür natürlich nur eine kleine Stichprobe erhoben, aber an dieser gesehen, dass sich kaum jemand die Mühe macht.

Interessant fand ich, dass man im Internet auf Meinungen stößt, dass diese Extension sinnlos ist und kaum eine CA sich darauf einlässt, diese in die von ihr ausgestellten Zertifikate zu integrieren.

Wird durch eine Verletzung des Name-Constraints das Ausstellen eines Zertifikats verhindert?

Also musste ich selber ran: Dazu nutzte ich die Expert PKI und erstellte damit zwei Identity-CAs. Mit beiden erstellte ich EMail-Signatur-Zertifikate, die ich in Thunderbird importieren wollte. Die beiden Zertifikate unterschieden sich in der Konfiguration des Name-Constraint: die betreffende Zeile lautete

nameConstraints		= critical,permitted;email:arcor.de

beziehungsweise

nameConstraints		= critical,permitted;email:mail.arcor.de

Leicht zu sehen, dass die zweite eigentlich nicht auf meine EMail-Adresse passt. Trotzdem stellte OpenSSL mit beiden CAs klaglos ein Zertifikat aus. Beim Erstellen prüft OpenSSL also nicht, ob die Daten des Zertifikatsrequests auf die Constraints im Zertifikat der ausstellenden CA passen.

Falls nicht - checken Clients die Name-Constraints und handeln sie entsprechend?

Damit musste ich nun prüfen, ob Name-Constraints wirklich komplett sinnfrei sind, oder ob Clients die benötigten Prüfungen durchführen.

Dazu erstellte ich aus den beiden Zertifikaten und dem privaten Schlüssel eine digitale Identität im p12-Format. Vor jedem Test entfernte ich etwaige vorhandene Reste der jeweils anderen digitalen Identität aus dem Zertifikatsspeicher von Thunderbird und das Zertifikat der ausstellenden CA aus der Liste der vertrauenswürdigen CAs.

Nun importierte ich zuerst das P12 und signierte eine EMail damit. Thunderbird tut das, ohne sich an den Constraints oder der fehlenden Information über den Aussteller zu beklagen. Liest man anschließend die EMail, meldet Thunderbird, dass die Signatur angezweifelt wird, da keine Informationen zum Aussteller vorliegen. Wird das CA-Zertifikat importiert, ändert sich die Fehlermeldung: Nun beschwert sich Thunderbird über die Tatsache, dass man das Zertifikat nicht für diesen Zweck freigegeben hat. Erst, nachdem man das CA-Zertifikat so konfiguriert hat, dass man ihm für den Anwendungsfall "EMail signieren" vertraut, war Thunderbird der Meinung, das CA eins ein gültiges Zertifikat ausgestellt hatte. Bei CA zwei (der mit dem Name-Constraint mail.arcor.de) blieb die Fehlermeldung bestehen.

Fazit

Die Tatsache, dass man trotz Widersprüchen zwischen Request und Name-Constraints Zertifikate ausstellen kann und diese erst - wenn überhaupt - bei der Prüfung und Validierung von Zertifikaten auffallen, zusammen mit der Tatsache, dass Clients diese Informationen nicht in für Anwender verständlicher Form präsentieren (Thunderbird zum Beispiel zeigt diese Erweiterung als Folge Hexadezimaler Zahlen an, denen ein normaler Anwender nicht entnehmen kann, was sie bedeuten) lässt für mich nur folgenden Schluss zu:

Durch den Einsatz dieser Erweiterung wird eine PKI nicht unsicherer - allerdings kann man sich nicht zurücklehnen, sobald man Name-Constraints konfiguriert hat: Man weiß nicht, ob Clients diese auch wirklich auswerten.

Alle Artikel rss Wochenübersicht Monatsübersicht Github Repositories Gitlab Repositories Mastodon Über mich home xmpp


Vor 5 Jahren hier im Blog

  • Mandelbrot-Sets mittels Shadern berechnen

    17.05.2019

    Nachdem ich in den letzten verregneten Tagen auf Youtube in den Videos von Numberphile versunken bin, hat mich eines davon angestachelt, mich selbst mit dem Mandelbrotset zu beschäftigen. Als ich dann noch Code fand, der behauptete, das auf einer Graphikkarte mittels Shadern berechnen zu können, war es um mich geschehen...

    Weiterlesen...

Neueste Artikel

  • Erste Vor-Version eines Gis-Plugin für die sQLshell

    Wie bereits in einem früheren Artikel erwähnt plane ich, demnächst ein Plugin für die sQLshell anzubieten, das eine Visualisierung von Daten mit räumlichem Bezug im Stil eines Geoinformationssystems erlaubt.

    Weiterlesen...
  • bad-certificates Version 2.1.0

    Das bereits vorgestellte Projekt zur automatisierten Erzeugung von Zertifikaten mit allen möglichen Fehlern hat eine Erweiterung erfahren und verfügt über ein Partnerprojekt - beide sind nunmehr in der Version 2.1.0 freigegeben

    Weiterlesen...
  • SQLite als Geodatenbank

    Wie bereits in einem früheren Artikel beschrieben treibe ich derzeit Anstrengungen voran, die sQLshell attraktiver für Nutzer zu machen, die mit Geodatenbanken arbeiten.

    Weiterlesen...

Manche nennen es Blog, manche Web-Seite - ich schreibe hier hin und wieder über meine Erlebnisse, Rückschläge und Erleuchtungen bei meinen Hobbies.

Wer daran teilhaben und eventuell sogar davon profitieren möchte, muß damit leben, daß ich hin und wieder kleine Ausflüge in Bereiche mache, die nichts mit IT, Administration oder Softwareentwicklung zu tun haben.

Ich wünsche allen Lesern viel Spaß und hin und wieder einen kleinen AHA!-Effekt...

PS: Meine öffentlichen GitHub-Repositories findet man hier - meine öffentlichen GitLab-Repositories finden sich dagegen hier.