it-swarm.com.de

Warum sind Wildcard-Zertifikate mit unendlicher Tiefe nicht zulässig?

Soweit ich das beurteilen kann, ist ein SSL-Zertifikat für *.example.com Gut für foo.example.com Und bar.example.com, Aber nicht für foo.bar.example.com.

Platzhalterzertifikate dürfen nicht *.*.example.com Als Betreff haben. Ich denke, dies liegt an der Tatsache, dass Zertifikate wie example.* Nicht zulässig sind. Das Zulassen von Zeichen vor dem Platzhalter kann dazu führen, dass ein böswilliger Benutzer sein Zertifikat mit der falschen Domain vergleicht.

Ich sehe jedoch kein Problem darin, Zertifikate der Sorte *.example.com Auf alle Subdomains, einschließlich Sub-Subdomains bis zu einer unendlichen Tiefe, anwenden zu lassen. Ich sehe keinen Anwendungsfall, in dem die Subdomains einer Site "vertrauenswürdig" sind, die Sub-Subdomains jedoch nicht.

Dies verursacht wahrscheinlich viele Probleme. Soweit ich das beurteilen kann, gibt es keine Möglichkeit, Zertifikate für alle Sub-Subdomains sauber abzurufen. Sie werden entweder eine Zertifizierungsstelle oder Sie kaufen Zertifikate für jede Subdomain.

Was ist der Grund dafür, *.example.com Nur auf Subdomains mit nur einer Tiefe zu beschränken?

Bonusfrage: Gibt es auch einen Grund für das generelle Verbot von Zeichen vor einem Platzhalter? Wenn Sie nur Punkte und Sternchen vor einem Platzhalter zulassen, kann die Site einer anderen Domain nicht gefälscht werden.

47
Manishearth

Technisch gesehen ist die Verwendung von Platzhaltern in RFC 2818 definiert, wobei Namen wie "*.*.example.com" Oder zulässt "foo.*.bar.*.example.com" Oder sogar "*.*.*". Zwischen Theorie und Praxis kann es jedoch beispielsweise praktische Unterschiede geben (Theorie und Praxis stimmen nur in der Theorie perfekt überein, nicht in der Praxis). Webbrowser haben strengere Regeln implementiert, weil:

  • Das Implementieren eines mehrstufigen Platzhalterabgleichs dauert gut fünf Minuten länger als das Implementieren des Abgleichs von Namen mit einem einzelnen Platzhalter.
  • Browser-Anbieter vertrauten der vorhandenen Zertifizierungsstelle nicht, weil niemals ein "*.*.com" - Zertifikat ausgestellt hat.
  • Entwickler sind Menschen, daher sehr gut darin, nicht zu sehen, was sie sich nicht vorstellen können. Daher wurden Multi-Wildcard-Namen nicht von Personen implementiert, die nicht erkannten, dass sie möglich waren.

Daher wenden Webbrowser Einschränkungen an, die RFC 6125 versucht, zumindest zu dokumentieren. Die meisten RFC sind Pragmatiker: Wenn die Realität nicht mit der Spezifikation übereinstimmt, ändern Sie die Spezifikation, nicht die Realität. Beachten Sie, dass Browser auch zusätzliche Regeln erzwingen, z. B. das Verbot von "*.co.uk" (Allerdings verwenden nicht alle Browser dieselben Regeln und sie sind auch nicht dokumentiert).

Professionelle Zertifizierungsstellen treten auch mit ihren eigenen Einschränkungen in den Tanz ein, z. B. Identitätsprüfungen vor der Ausstellung von Zertifikaten oder einfach die mangelnde Bereitschaft, zu breite Wildcard-Zertifikate auszustellen: Das Kerngeschäft einer professionellen Zertifizierungsstelle besteht darin, viele zu verkaufen Zertifikate und Platzhalterzertifikate helfen dabei nicht. Im Gegenteil. Leute wollen Wildcard-Zertifikate genau kaufen, um zu vermeiden, dass viele einzelne Zertifikate gekauft werden.


Eine andere Theorie, die es nicht in die Praxis geschafft hat, ist Name Constraints . Mit dieser X.509-Erweiterung kann eine Zertifizierungsstelle ein Zertifikat an eine Unterzertifizierungsstelle ausstellen, wodurch diese Unterzertifizierungsstelle eingeschränkt wird, sodass Serverzertifikate nur in einer bestimmten Domänenstruktur ausgestellt werden können. Eine Name Constraints - Erweiterung mit einem "expliziten Teilbaum" mit dem Wert ".example.com" Würde www.example.com Und foo.bar.example.com Erlauben. In diesem Modell würde der Eigentümer der Domäne example.com Seine eigene Zertifizierungsstelle ausführen, die durch ihre Über-Zertifizierungsstelle auf nur Namen im Teilbaum example.com Beschränkt ist. Das wäre in Ordnung und gut.

Leider ist alles, was Sie mit X.509-Zertifikaten tun, völlig wertlos, wenn bereitgestellte Implementierungen (d. H. Webbrowser) dies nicht unterstützen und vorhandene Browser keine Namensbeschränkungen unterstützen. Sie tun dies nicht, da kein Zertifikat mit Namensbeschränkungen zu verarbeiten ist (das wäre also nutzloser Code), und es gibt kein solches Zertifikat, da Webbrowser sie sowieso nicht verarbeiten könnten. Um bootstrap things, ) muss jemand den Zyklus starten, aber Browser-Anbieter warten, nachdem die professionelle Zertifizierungsstelle und die professionelle Zertifizierungsstelle nicht bereit sind Namensbeschränkungen aus den gleichen Gründen wie zuvor zu unterstützen (die auf lange Sicht alle auf Geld hinauslaufen).

22
Thomas Pornin

Wie in den Kommentaren erwähnt, erklärt RFC6125 dies ziemlich gut (Auszug aus Abschnitt 7.2 )

Die Spezifikationen für vorhandene Anwendungstechnologien sind hinsichtlich der zulässigen Position des Platzhalterzeichens nicht klar oder konsistent.

...

Diese Mehrdeutigkeiten können zu ausnutzbaren Unterschieden im Identitätsprüfungsverhalten zwischen Client-Implementierungen führen und übermäßig komplexe und ineffiziente Identitätsprüfungsalgorithmen erfordern.

Grundsätzlich wird dieses Verhalten erzwungen, um die Überprüfung zu vereinfachen und damit die Sicherheit zu erhöhen.

6
drak