Avatar von Valentin Hilbig
  • Valentin Hilbig

mehr als 1000 Beiträge seit 08.01.2000

Altruismus === Protocol Violation

fernkämpfer schrieb am 13.09.2017 14:37:

Valentin Hilbig schrieb am 13.09.2017 13:50:

- Allquantor-Certs werden erst ab Januar 2018 angeboten, und sie gibt es noch nicht für Subdomains (also *.example.com wird es geben, *.sub.example.com wird es vorerst nicht geben, d. h. man kann es nicht für DDNS etc. a la *.home1.example.com).

Wo nimmst du das her? Es werden ab Januar beliebige Wildcard-Zertifikate unterstützt.

Das entnehme das aus folgender Passage:

https://letsencrypt.org/2017/07/06/wildcard-certificates-coming-jan-2018.html

We will initially only support base domain validation via DNS for wildcard certificates, but may explore additional validation options over time.

Also: Die Base-Domain von "*.sub.example.com" ist nach meinem Verständnis "example.com" und nicht "sub.example.com". Wenn ich also den DNS einer Domain wie "sub.example.com" delegiere, wird derjenige kein Wildcard bekommen, da dies ja keine "Base-Domain" ist.

Mag sein, dass LetsEncrypt unter "Base Domain Validation" etwas anderes versteht als ich, aber das stellt der Text leider nicht klar und ich bin nicht der einzige, der das wohl so versteht.

Bei Wildcard-Certs ist alles nicht so einfach, und ich fände es gut und richtig, wenn LetsEncrypt erst einmal nur "den obersten Level" einführt, und keine großen Experimente macht. Beim Delegieren von Subdomains usw. kann man so unendlich viele Fehler machen, dass das mit der DNS-Validierung bei Subdomains ziemlich grausam enden kann.

Ich lasse mich aber gerne überraschen, dass ich das zu pessimistisch sah, also unter "Base Domain" einfach alles ohne den Allquantor verstanden wird. Allerdings sollte man da als der übergeordnete DNS einen Riegel vorschieben können, also wenn ich z. B. die Domain sub.example.com delegiere, möchte ich evtl. nicht, dass mir da jemand dann den ganzen Raum dunter mit einem Wildcard-Cert zuballert, ohne dass ich das von oben kontrollieren kann.

CAA hilft in diesem Fall leider auch nicht weiter, da die Einträge blöderweise im selben delegierten Pfad liegen. Mal wieder etwas, das im Standard aus Kurzsichtigkeitsgründen letztendlich vergeigt wurde, so wie eigentlich alles in den letzten 20 Jahren. Was ich meine, dass es so etwas wie _caa.example.com in der Parentaldomain nicht gibt, für das man die Policy der Subdomain hätte überschreiben können.

Und genau deshalb, also weil es genau das NICHT gibt, finde ich, wäre es ratsam, bei automatisierten Systemen a la LetsEncrypt so neue Dinge sehr behutsam einführt, statt es zu übereilen.

Außerdem wäre ein "_caa.example.com" auch in anderer Hinsicht sinnvoll, nämlich dann, wenn es zu einem Fehler kommt. Auch mit DNSsec (von dem ich überhaupt nichts halte) bleibt es möglich, negative Antworten zu unterdrücken. Weil DNSsec eben nicht bis zum Client validiert. Sprich, es wäre sinnvoll, bei der Einführung von CAA vorzuschreiben, dass Domains ein "_caa"-Eintrag haben müssen, damit sie SSL-Certs beantragen können. Ja, so richtig auf die harte Tour! Wer CAA nicht will, kann da _caa.example.com TXT "*" reinschreiben, sprich, es gibt keine Einschränkung. (Das stünde für "* 0 issuewild *", was wiederum eine Erweiterung von CAA wäre, in dem nicht nur der derzeitige, sondern auch der historische und der zukünftige Standard gelistet werden könnte, also "ISODATE FLAG TYPE DOMAIN" und "*" ist eine Shell-regex, der übliche Allquantor.)

Dann wäre sichergestellt, dass solch ein Eintrag da sein muss, und dann hätte man sich evtl. den ganzen Zinnober mit der Voraussetzung eines neuen Ressource-Types sparen können (Fallback zum weniger effizienten TXT), der total unsensibel eingeführt wurde und alleine schon durch seine Existenz zahlreiche Probleme bereiten konnte, bevor er überhaupt genutzt wurde!

In dem Zusammenhang ist ja wichtig, dass CAA für CAs ist und weniger für Browser, d. h. der Overhead eines Fallback ist zu verschmerzen. (Richtung Browser/Clients könnte man ja den Fallback auf TXT "nicht empfohlen" stellen, d. h. wer den CAA-Record irgendwann mal bis zum Browser durchreichen will, muss dann halt CAA nutzen. Das wird heute aber nicht gebraucht.)

Aber so .. vergeigt. Wenn man wirklich etwas für die Sicherheit machen will, muss man den Default grundsätzlich hart auf "DENIED" stellen. Aber so wird das nie etwas, wenn man selbst in den Ausnahmefällen wie bei CAA nicht tut, in denen die Sicherheit die Freiheit eben in keinster Weise beeinträchtigt.

-Tino
PS: Und warum ist das wichtig? Ganz einfach: Ich delegiere eine Subdomain, weiß aber, in 27 Monaten wechselt die Nutzung der Domain. Nun muss ich sicherstellen, dass Sub-Domains keine Certs bekommen, die über die 27 Monate hinausgehen. Irgendwie logisch, oder nicht? Hat mal daran jemand gedacht? Oder haben die vielen $$$ da mal wieder die Sicht auf das Wesentliche verstellt, nämlich dass es auch Leute im Internet gibt, die zum Wohle der Community Dinge machen, wie z. B. eine Domain für andere KOSTENLOS bereitzustellen, bis sie dann für andere Zwecke gebraucht werden - und dann dürfen eben keine "wilden Zertifikate" mehr rumliegen, sonst kann ich die Domain nicht freigeben. Nö, interessiert niemand. Armes Internet, was ist nur aus Dir geworden! Denn inzwischen verstößt Altruismus gegen all die schönen neuen Protokolle die ohne Sinn und Verstand eingeführt werden!

Bewerten
- +
Anzeige