TLDR: Eine Hand voll Shared-Hosting-Anbietern ist im Moment von einer Lücke im Zusammenhang mit Let’s Encrypts tls-sni-01 Challenge betroffen. Wir nicht. Warum steht weiter unten.

Let’s Encrypt unterstützt neben der bekannten http-01 Challenge (das ist die mit den wunderschönen /.well-known/acme-challenge/evaGxf...-URLs) auch andere Validierungsformen wie dns-01 (involviert “Magic”-Records im DNS) und auch tls-sni-01. In diesem Fall findet die Validierung im TLS-Protokoll selbst, noch vor HTTP statt. Dazu müssen spezielle, selbst-signierte Zertifikate ausgeliefert werden. Die von euch, die das genauer interessiert: hier geht’s lang zum Standard-Dokument.

Nun hat ein Sicherheitsforscher Probleme mit der Implementation von tls-sni-01 bei vielen Shared-Hosting-Anbietern gefunden. Diese Lücke ermöglicht es einer Angreiferin Zertifikate für fremde Domains auf dem selben Host (bzw. unter der selben IP-Adresse) zu erhalten. Wenn es gerade eben darum geht festzustellen, ob dem Antragssteller die angefragte Domain überhaupt gehört, ist das eher ungut.

Wir sind von dieser Lücke bei …

• … Uberspace 6 nicht betroffen, weil unser uberspace-add-certificate ausschließlich Zertifikate zulässt, die von einer offiziellen CA ausgestellt wurden. Die für den Angriff notwendigen Zertifikate schaffen es also gar nicht bis in den Webserver.
• … Uberspace 7 nicht betroffen, weil a) wir dort auf http-01 setzen und b) dort im Moment keine eigenen Zertifikate möglich sind.

Wir wünschen also fröhliches und sicheres weiterbasteln! :)

• ← Previous Post
• Next Post →