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

  • Virtuelles Netzwerklabor

    11.01.2017

    Nachdem ich hin und wieder vor der Herausforderung stehe, Anwendungen unter realen Netzwerkbedingungen zu testen, habe ich bereits vor längerer Zeit begonnen, ein virtuelles Netzwerklabor aufzubauen...

    Weiterlesen...

Neueste Artikel

  • Stratum-1-NTP-Server Links

    Ich habe meinen eigenen Stratum-1-NTP-Server mittels eines GPS-Empfängers, einer Adapterschaltung und einem Raspi gebaut. Hier fasse ich einige nützliche Links zu diesem Themengebiet zusammen

    Weiterlesen...
  • EBCMS threaded und mit mehr Markdown-Unterstützung

    Mein eigener Static Site Generator hat in den letzten Wochen einige größere Umbauten erfahren

    Weiterlesen...
  • Fork der BeanShell wegen Trojan Source

    Es gibt inzwischen einen von mir erstellten Fork des originalen Repository, in dem ich die Komponente zur Darstellung der Konsole gegen die ausgetauscht habe, die in der sQLshell in den Plugins MDIJavaEditor und MDISqlEditor zum Einsatz kommt - dadurch wird wenigstens durch das Syntax-Highlighting auf problematische Stellen im Code hingewiesen.

    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.