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

Warum?

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?

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?

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?

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

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.

Kommentar hinzufügen (via ) Kommentare ansehen (via )

Kommentar hinzufügen (via ) Kommentare ansehen (via )