3 Punkte von GN⁺ 2024-11-21 | 1 Kommentare | Auf WhatsApp teilen
  • Da im Internet immer häufiger persönliche und geschäftliche Informationen ausgetauscht werden, trat Let’s Encrypt als Zertifizierungsstelle auf den Plan, die mit kostenlosen Serverzertifikaten die Einstiegshürde für die Verbreitung von TLS senken wollte.
  • Browser und Server unterstützen TLS bereits, doch für Betreiber waren Ausstellung, Installation und Erneuerung von Zertifikaten kompliziert und zudem kostenpflichtig.
  • Mozilla, Cisco, Akamai, EFF, IdenTrust und Forscher der University of Michigan arbeiteten über die ISRG zusammen und trieben im 2. Quartal 2015 die Bereitstellung der Infrastruktur voran.
  • Die Betriebsprinzipien sind kostenlos, automatisiert, sicher, transparent, offen und kooperativ; dazu gehören die Veröffentlichung von Ausstellungs- und Widerrufsprotokollen sowie offene Standardprotokolle.
  • Im Fokus steht nicht Sicherheit unter der Kontrolle einzelner Organisationen, sondern der Aufbau einer universellen und offenen Internetsicherheit, die von der gesamten Community genutzt werden kann.

Die Hürde von Serverzertifikaten, die die Verbreitung von TLS bremste

  • Persönliche und geschäftliche Informationen werden immer häufiger über das Internet übertragen, doch Nutzer können oft nicht erkennen, wann solche Übertragungen stattfinden.
  • TLS ist die Nachfolgetechnologie von SSL und wird bereits von Browsern auf allen Geräten sowie von Servern in Rechenzentren unterstützt.
  • Der Kern TLS-geschützter Kommunikation ist ein Public-Key-Zertifikat, das belegt, dass der Nutzer tatsächlich mit dem beabsichtigten Server kommuniziert.
  • Für viele Serverbetreiber blieb selbst ein einfaches Serverzertifikat eine Belastung.
    • Der Antragsprozess kann verwirrend sein.
    • In der Regel fallen Kosten an.
    • Die korrekte Installation ist schwierig.
    • Die Erneuerung ist umständlich.

Die von Let’s Encrypt vorgeschlagene kostenlose und automatisierte Zertifizierungsstelle

  • Let’s Encrypt ist eine neue kostenlose Zertifizierungsstelle, die auf Zusammenarbeit und Offenheit basiert.
  • Domaininhaber können für ihre Domain ein verifiziertes Standard-Serverzertifikat über ein One-Click-Verfahren erhalten.
  • Mozilla Corporation, Cisco Systems, Akamai Technologies, die Electronic Frontier Foundation, IdenTrust und Forscher der University of Michigan arbeiten über die Internet Security Research Group (ISRG) zusammen.
  • Die ISRG ist eine gemeinnützige Körperschaft in Kalifornien und begrüßt die Beteiligung weiterer Organisationen mit demselben Ziel.
  • Die Betriebsprinzipien sind wie folgt:
    • Kostenlos: Domaininhaber können für die jeweilige Domain kostenlos ein verifiziertes Zertifikat erhalten.
    • Automatisiert: Die Zertifikatsregistrierung erfolgt während der Standardinstallation oder Konfiguration des Servers, und die Erneuerung wird automatisch im Hintergrund durchgeführt.
    • Sicher: Die Plattform dient als Grundlage für die Umsetzung aktueller Sicherheitstechniken und Best Practices.
    • Transparent: Aufzeichnungen über die Ausstellung und den Widerruf von Zertifikaten werden veröffentlicht, damit sie von jedermann überprüft werden können.
    • Offen: Protokolle für automatische Ausstellung und Erneuerung werden als offene Standards entwickelt, und so viel Software wie möglich wird als Open Source bereitgestellt.
    • Kooperativ: Der Betrieb erfolgt als gemeinschaftliche Anstrengung zum Nutzen der gesamten Community, ähnlich wie Internetprotokolle.
  • Informationen zur ISRG und ihren Partnern finden sich auf der Seite About.

1 Kommentare

 
GN⁺ 2024-11-21
Meinungen auf Hacker News
  • Zweifellos einer der besten Dienste überhaupt; er hat dem Zertifikate-Geschäft ein Ende gesetzt und das Internet sicherer gemacht.
    Früher waren HTTPS-Verbindungen etwas für „ernsthafte“ Projekte, weil die Zertifikatskosten deutlich höher waren als die Domain selbst. Man startete erst einmal ohne Zertifikat, und wenn es gut lief, zahlte man etwa 100 Dollar und kaufte eines.

    • Es gibt immer noch ziemlich viele Leute, die es nicht besser wissen und wie 2013 jedes Jahr direkt bei ihrem Hosting-Anbieter ein Zertifikat kaufen oder für automatische Verlängerung zahlen.
    • Ein schlampig konfigurierter Proxy war so eingestellt, dass er für jede eingegebene Domain ein Zertifikat anforderte; ein Angreifer fand das heraus und schickte fortlaufend HTTP-Requests mit zufälligen Subdomains.
      Als ich es bemerkte, dachte ich nicht zuerst: „Was, wenn Let’s Encrypt mich sperrt?“, sondern: „Es tut mir leid, dass meine faule Konfiguration Let’s Encrypt unnötig belastet.“ Let’s Encrypt ist zumindest in den letzten zehn Jahren das Beste, was dem Web passiert ist.
    • Mozilla bekommt viel Kritik, aber allein letsencrypt macht die Welt schon zu einem besseren Ort.
      Davor habe ich für meine Dienste überhaupt kein SSL verwendet, weil Kosten und Nutzen nicht zusammenpassten. Seitdem verzichte ich nie darauf.
    • Auch früher gab es Dienste, bei denen man kostenlos ein „echtes“ Zertifikat für eine einzelne Domain bekommen konnte, aber der Ablauf war kompliziert und lästig.
      Wenn man für persönliche Projekte ein Wildcard-Zertifikat brauchte, das mehrere Subdomains abdeckt, wurde es plötzlich sehr teuer. Schön, dass dieses Problem vollständig gelöst wurde.
    • Auch Google/Chrome und Firefox haben ihren Anteil daran, dass eine kostenlose und offene Zertifizierungsstelle möglich wurde.
  • Nach unserem Maßstab betrachten wir 2025 als das zehnjährige Jubiläum, aber wir wissen die warmen Worte hier zu schätzen.
    Heute ist es ungefähr zehn Jahre her, dass wir öffentlich angekündigt haben, Let’s Encrypt starten zu wollen; nächstes Jahr sind es zehn Jahre, seit Let’s Encrypt tatsächlich das erste Zertifikat ausgestellt hat: https://letsencrypt.org/2015/09/14/our-first-cert/
    Im Dezember 2015, also aus heutiger Sicht vor etwa neun Jahren, wurde der Dienst ohne Einladung für alle nutzbar: https://letsencrypt.org/2015/12/03/entering-public-beta/.

    • Dass es genau im Dezember 2015 so weit war, passte für mich zufällig perfekt.
      Damals hatte ich nur Geld für die Domain, aber nicht für SSL, obwohl die Website SSL brauchte. Dank des kostenlosen SSL von Let’s Encrypt wurde das Projekt ein Erfolg.
  • Es fühlt sich an, als wäre es gestern gewesen, dass man für Zertifikate bezahlt hat – und schlimmer noch, es gab auch Zeiten, in denen man ganz ohne betrieben hat.
    Kaum zu glauben, dass es schon 10 Jahre sind.

    • Kaum zu glauben, dass es immer noch TLS-Gegner-Nerds gibt.
  • Bei Let’s Encrypt bin ich etwas zwiegespalten.
    Es ist gut, dass man kostenlose TLS-Zertifikate bekommen konnte, ohne sich auf dubiose Anbieter wie StartSSL zu verlassen. Dadurch ließ sich jede Website leicht auf HTTPS umstellen, und dass sensible Daten wie Logins über unverschlüsselte Verbindungen übertragen werden, ist praktisch verschwunden.
    Andererseits denke ich, dass es die grundsätzlich kaputte Struktur des Vertrauensmodells für TLS-Zertifikate gestärkt hat, bei dem jede Zertifizierungsstelle ohne meine Beteiligung ein Zertifikat für meine Domain ausstellen kann. Es gibt viele Abhilfen wie CAA-Records oder Certificate Transparency, aber keine davon ist eine 100-%-Lösung. Ohne Let’s Encrypt hätte es vielleicht stärkere Anreize gegeben, bessere Vertrauensmechanismen wie DNSSEC+DANE umzusetzen, die die Zertifikatsausstellung auf die Instanz beschränken, die tatsächlich berechtigt ist, über Domain-Eigentum zu entscheiden.
    Sorgen macht mir auch die absichtlich geringe Abwärtskompatibilität beim Umstieg von Websites auf TLS. Das ist nicht einfach eine einmalige Frage von TLS an oder aus, sondern ein fortlaufendes Ausmustern von Protokollen und Cipher Suites. Für Dinge, die sicher sein müssen, wie Banking oder E-Mail, ist das sinnvoll, aber für statische, unkritische Informationen wie Rezepte halte ich es nicht unbedingt für nötig. Probleme wie das Einfügen von Werbung oder sonstigem Unsinn durch Provider ließen sich meiner Meinung nach besser durch Regulierung lösen.

    • Zu dem Punkt, dass es ohne Let’s Encrypt Anreize gegeben hätte, bessere Vertrauensmechanismen zu implementieren: Ich sehe es eher so, dass Let’s Encrypt diese Probleme stärker sichtbar gemacht hat und die zuständigen Leute sich nun tatsächlich Sorgen darüber machen.
      Wenn Zertifikate weiterhin schmerzhaft geblieben wären, wäre vielleicht etwas Besseres als TLS entstanden, aber danach sieht es nicht aus. Das Grundproblem ist nämlich weiterhin schwierig.
  • Am dankbarsten bin ich für das ACME-Protokoll
    Erinnert ihr euch noch, wie man Zertifikate vor Let’s Encrypt erneuert hat? Private Keys wurden als ZIP-Anhänge per E-Mail hin- und hergeschickt. Das war eher Sicherheitstheater, und soweit ich weiß, war das bei mehreren Zertifizierungsstellen gängige Praxis. Danke, Let’s Encrypt

    • Ich bearbeite GlobalSign-Erneuerungen immer noch manuell
      Beim Erstellen des CSR erzeuge ich auf dem Server einen neuen Schlüssel und lasse den Prozess auf dem Server selbst laufen, damit der Schlüssel den internen Speicher des Servers nicht verlässt. Der CSR geht an GlobalSign, läuft wegen Konzernprozessen über einen Dritten, und ein paar Tage später kommt das Zertifikat zurück und wird auf dem Server eingespielt
      Ich würde gern ACME nutzen und den Schlüssel etwa in einem RAM-Disk im Speicher halten, aber das ist eben der Nachteil, wenn man in einem Unternehmen arbeitet, das weniger wendig ist als ein Öltanker
    • Wo sind die Certificate Signing Requests geblieben? Ihr ursprünglicher Zweck war es, keine Private Keys austauschen zu müssen
      Davor war ich nur am Rande mit ein paar TLS-Zertifikaten befasst, aber zumindest an den Stellen, die ich erlebt habe, wurde das CSR-Verfahren erzwungen. In der Praxis waren solche schrecklichen Gewohnheiten aber vielleicht verbreiteter, als ich wusste
    • Ob man Let’s Encrypt nutzt oder nicht: Wenn man etwas als ZIP-Datei verschickt, sollte es der Public Key sein, nicht der Private Key
    • In manchen meiner Setups muss ich solchen Unsinn immer noch machen
      Load Balancer in Cloud-Umgebungen lassen sich oft nicht einfach mit externen ACME-Anbietern wie letsencrypt integrieren, und interne Anbieter verlangen, dass man die Domain zu ihnen umzieht, was nicht immer möglich ist. Nicht einmal alle Cloud-Anbieter haben so eine Funktion, und die meisten scheinen ACME wie ein nachträglich angeflanschtes Feature zu behandeln
      Mit terraform, Cronjobs und Ähnlichem kann man sich per Skript irgendwie behelfen, aber es wird unsauber. Der Fehlermodus ist: Wenn die Zertifikatserneuerung scheitert, steht die Site still; und weil Zertifikatslaufzeiten sehr kurz geworden sind, passiert das entsprechend häufig. Habe ich selbst erlebt
      Deshalb habe ich vor ein paar Tagen die Wildcard-Zertifikatssteuer bezahlt. Ich habe ein paar hundert Dollar gezahlt, um mir nicht den Kopf darüber zerbrechen zu müssen. Das fühlt sich unschön an, aber es lohnt sich nicht, mehrere Tage zu investieren, nur um Kosten zu sparen, die bei meiner Zeit effektiv weniger als 2 Stunden ausmachen. CSR ausstellen, Zertifikat erhalten und auf die betreffenden Load Balancer kopieren ist ein 20-Minuten-Job
    • Wie viele dieser Zertifizierungsstellen stehen heute wohl noch in den Trust Stores aller Nutzer?
  • Ich wünschte, so etwas gäbe es auch in der Welt der Desktop-Zertifikate
    Microsoft ist bei seinen aktuellen Anforderungen völlig in den Wahnsinnsmodus abgebogen, und ihre Zertifikatsverkäufer verdienen ohne einen Finger zu rühren mehr Geld als früher
    Das Lustige ist, dass all diese Sicherheit, Audits und endlosen Prüfungen immer noch auf einem per E-Mail verschickten Passfoto beruhen

  • Peter Eckersley (1978–2022) wurde für seine Gründungsarbeit an Let’s Encrypt posthum in die Internet Hall of Fame aufgenommen
    Dank Peter und seinen vielen Mitstreitern und Kollegen ist das Internet ein besserer Ort geworden

  • Passenderweise habe ich gerade eine E-Mail von einer potenziellen Kundin, einer niederländischen Regierungsbehörde, bekommen, in der sie darum bittet, Letsencrypt nicht zu verwenden
    Sie bevorzugen offenbar, dass sie die Zertifikatskosten übernehmen; warum, weiß ich nicht. Sie scheinen dem Ganzen wohl nicht zu vertrauen

  • Viele Menschen wissen nicht, dass HTTPS-Zertifikate bestimmte Angriffsarten wie DNS-Injection nicht zwangsläufig verhindern
    Ein Beispiel dafür, wie die Angriffskampagne DNSPionage gültige Zertifikate für ihre Angriffe erhielt, gibt es unter <https://www.youtube.com/watch?v=exy5JwAU8qk>
    Kurz gesagt: Die Ausstellung von HTTPS-Zertifikaten ist automatisiert und hängt von DNS-Sicherheit ab; die erreicht man mit DNSSEC, was die meisten aber nicht implementieren

    • Technisch gesehen ist es ein Angriff auf die Zertifizierungsstelle und umgeht die Autorisierungsprüfung: „Ist diese Person wirklich berechtigt, ein Zertifikat für diese Domain ausstellen zu lassen?“
      Das Problem ist, dass CAA-Einträge hier auch nicht helfen. Wenn man A-Records fälschen kann, kann man auch CAA-Records fälschen. Ob DNSSEC hier helfen würde, kann ich nicht sicher sagen, dafür kenne ich DNS nicht gut genug
      Ein anderer Angriff ist IP-Hijacking. In diesem Fall kann man zwar typische ACME-Methoden wie HTTP-Validierung bestehen, aber CAA-Records nicht umgehen. Selbst wenn jemand die IP-Adresse besitzt, auf die mein A- oder AAAA-Record zeigt: Wenn in meinem CAA letsencrypt nicht als zugelassener Aussteller steht, kann er mit letsencrypt kein Zertifikat ausstellen lassen
  • Let’s Encrypt ist eine enorme Leistung und inzwischen unverzichtbare Infrastruktur
    Es war eine kluge Entscheidung, auf offene Protokolle zu setzen, damit es nicht zu einem Single Point of Failure wird und die Idee weiterlebt, selbst wenn eine einzelne Organisation verschwindet
    Ich hoffe, dass noch viele solcher Jubiläen folgen