Let's Encrypt

Mitte 2014 bin auch auf die Aktion "Let's Encrypt" (https://letsencrypt.org) aufmerksam geworden, die SSL-Zertifikat für jeden verspricht. Ein hohe Ziel, aber ist es auch erreichbar ?

Die Idee dahinter

Die Macher sehen einen Bedarf für eine generelle Verschlüsselung aller Daten, um die Privatsphäre der Internetnutzer zu sichern. Dem kann ich zustimmen, da mit mit einer guten Verschlüsselung das mitschneiden auf dem Transportweg unmöglich oder zumindest erschwert wird. Allerdings muss immer noch hinterfragt werden, wer Zertifikate ausstellt und welchen Zugriff "böse Teilnehmer" auf das Zielsystem haben, auf dem die Daten natürlich entschlüsselt vorliegen. Gegen wir mal davon aus, dass "Let's Encrypt" eine seriöse PKI ist und man darauf vertrauen kann, dass von ihr ausgestellte Schlüssel auch nur für den legitimen Antragsteller ausgestellt werden, dann ist dies eine gute Idee. Die wesentlichen Fakten sind:

  • Zertifikate sind kostenfrei
    Damit ist die erste Hürde schon mal genommen. Es kann nicht am Geld scheitern, auf SSL zu verzichten.
  • Zertifikate sind "Domain Namen Zertifiziert" 
    Die Überprüfung der Legitimation erfolgt über DNS oder HTTP. Wenn Sie DNS-Admin sind und die richtigen Einträge machen können oder auf dem Webserver eine Datei ablegen können, dann ist das hinreichend um das Zertifikat anzufordern. Die meisten kommerziellen Zertifizierungsstellen bieten als günstigste Variante diesen Weg an.
  • Keine "Extended Validation"-Zertifikate
    Mit "Let's Encrypt" ist es aktuell aber nicht möglich, "Extended Validation"-Zertifikate zu erhalten. Einen grünen Hintergrund in der Adressleiste wird so nicht zu sehen sein.
  • SAN-Zertifikate
    Von Let's Encrypt ausgestellte Zertifikate können mehrere Namen enthalten.
  • Keine Wildcard
    Es ist aktuell wohl nicht geplant, Wildcard-Zertifikate auszustellen
  • 90 Tage gültig - Automatismus erforderlich
    Die ausgestellten Zertifikate sind allesamt nur 90 Tage gültig. Let's Encrypt baut darauf auf, dass ein automatischer Prozess auf dem Server das Zertifikat immer wieder erneuert. Damit reduziert man natürlich auch das Risiko, wenn ein Zertifikat "geklaut" wird.
  • Port 80 für Challenge
    Um die Identität zu prüfen, muss der Client auf dem Webserver eine mit dem eigenen Private-Key signierte Datei ablegen, die von Let's Encrypt geladen und verifiziert wird. Das geht nur über Port 80. Ein anderer Port ist nicht möglich, da ansonsten z.B.: das Risiko besteht, dass ein User-Prozess auf einem nicht privilegierten Port (Unix) sich ein Zertifikat für den Namen besorgt.
  • Eigener Server, kein Shared Hosting
    Die Plattform ist dafür gedacht, wenn Sie zumindest einen WebServer mit eigener fester IP-Adresse selbst betreiben oder hosten. Alle Webseiten, die ein "Shared Hosting" nutzen können in der Regel kein SSL-Zertifikat selbst einbinden und scheiden daher als Nutzer aus. Sie müssen also schon ein Stück weit Serveradministrator sein.

Für den normalen Einsatz benötigen Sie also einen Webserver, auf dem ein Skript automatisch eine Datei anlegen kann, um von Let's Encrypt immer wieder ein aktuelle Zertifikate zu erhalten. 

Das ganze System funktioniert natürlich nur, wenn die RootCA auch vertrauenswürdig ist. Das sollte aber mittlerweile bei vielen Clients gegeben sein.

So funktioniert es

Die grundlegende Funktion hat Let's Encrypt natürlich auch selbst veröffentlicht:

Die Schritte im Einzelnen:

  1. DNS, Webserver und Schlüssel
    Zuerst muss der Administrator natürlich dafür sorgen, dass es einen DNS-Eintrag für den gewünschten Namen gibt, der auch einen Webserver erreicht, der später von Let's Encrypt angesprochen unter Port 80 angesprochen werden kann.
  2. Schlüssel rechnen
    Zertifikate haben immer was mit privaten und öffentlichen Schlüsseln zu tun. Der Let's Encrypt Client muss daher ein Schlüsselpaar erzeugen.
  3. Aufgabe von Let's Encrypt anfordern
    Der Prozess startet damit, dass der Let's Encrypt Client zum Let's Encrypt Service geht und eine Aufgabe für den FQDN anfordert.
  4. Antwort von Let's Encrypt
    Let's Encrypt liefert dann die Optionen, die der Client verwenden kann. Meist wird man hier eine Datei auf dem Webserver ablegen wollen
  5. Datei erstellen
    Die Aufgabe von Let's Encrypt besteht z.B.: darin, eine Datei mit einem Nounce zu erstellen und mit dem privaten Schlüssel zu signieren. Diese Datei muss dann unter dem vorgegebenen Namen auf dem Webserver bereit gestellt werden
  6. Benachrichtigung an Let's Encrypt
    Nun kann der Let's Encrypt Client erneut mit Let's Encrypt in Kontakt treten und damit den Prozess anstoßen
  7. Let's Encrypt holt die Datei
    Der Service versucht von seinerseits von extern diese Datei vom Webserver unter dem früher als Aufgabe gelieferten URL abzuholen. Die erfolgreich erhaltene Datei wird mit dem in Schritt 6 übermittelten Public Key verifiziert und nur wenn dann der Inhalt (Nounce) übereinstimmt, unterschreibt Let's Encrypt den gesendeten PublicKey
  8. Let's Encrypt sendes das Zertifikat zurück
    Der Let's Encrypt Client bekommt als Antwort auf seinen Request das unterschriebene Zertifikat zurück.
  9. Einspielen des Zertifikats
    NNun ist es am Let's Encrypt Client das Zertifikat (Unterschriebener Public Key) und den privaten Schlüssel auf dem Webserver einzuspielen. Der Clients sollte in dem Zuge auch gleich noch die Intermediate Zertifikate mit installieren.

Diese Prozesse müssen mindestens alle 90 Tage erfolgreich laufen, ein Monitoring ist also dringend angeraten. Zudem muss der Client mit dem entsprechenden Service umgehen können, um ein neues Zertifikat quasi "on the fly" zu tauschen. Es ist aber nicht zwingend erforderlich, dass der WebServer, welcher von "Let's Encrypt" angesprochen wird auch der gleiche ist, auf dem das Zertifikat liegt. Wer z.B.: viele Zertifikate für interne Hosts mit einem öffentlichen FQDN ausstellen will, könnten durchaus einen Webserver aus dem Internet erreichbar machen und per Wildcard-DNS einfach alle Namen auf diesen Server leiten. Der interne Let's Encrypt-Client müsste die Aufgabendatei dann nur zu diesem Webserver hochladen können.

Clients

Durch die kurze Gültigkeitsdauer von 90 Tagen, muss ein Server sein Zertifikat immer wieder erneuern. Das geht sinnvoll nur automatisch. Daher ist ein geplanter Task und eine entsprechend privilegierte Software (Client) erforderlich, der die Schritte auf dem Server durchführt. Let's Encrypt hat zuerst einen native Client für Linux basierend auf PHP veröffentlicht, welcher einen Apache2 konfiguriert. Da die API aber offen ist und auch PHP-Skripte "lesbar" sind, ist es nur eine Frage der Zeit, bis andere Plattformen auch unterstützt werden oder die Funktion sogar in Produkte integriert wird.

Kann es denn funktionieren?

Die einfache Installation eines Zertifikats auf einem Server ist nur ein Teil der Konstruktion.

  • Vertrauenswürdigkeit der PKI
    Damit SSL sinnvoll genutzt werden kann, muss aktuell noch eine PKI betrieben werden, die auf möglichst vielen Clients als "Vertrauenswürdig" angesehen wird. Es wird dauern, bis die neue CA auf Clients vorliegt. Speziell mobile Clients, Smartphones, Tablets etc. sind da eher ein Hindernis, auch wenn viele nach 2 Jahren getauscht werden und nach 4-5 Jahren auch als Zweitgerät entsorgt werden. Die CA muss es zumindest in die Stamm-Liste bei FireFox, Windows, Unix und andere Browser Clients schaffen. Ich bin gespannt, ab wann die kritische Menge an Clients erreicht ist, die dieser neuen CA vertrauen.
  • PKI und DoS
    Je mehr Systeme eine CA nutzen, desto interessanter ist es für Kriminelle, deren Betrieb zu stören um wirtschaftliche Vorteile zu ziehen. Viele Webseiten mit einem Zertifikat und noch mehr Benutzer, die darauf zugreifen, ergeben viele CRL-Request, um den Status des Zertifikats zu prüfen. Die aufzubauende PKI muss diese Anforderungen bedienen können. Das ist nicht mal eben gemacht. Insbesondere könnte es interessant werden, da alle Clients nach 90 Tagen ihr Zertifikat verlängern müssen.
  • Kosten
    Damit steigen auch die Kosten für den Betrieb. Es ist löblich, wenn es Sponsoren gibt, die sich hier engagieren aber Sponsoren können je nach wirtschaftlicher Lage sich auch wieder zurückziehen. Der Betrieb einer CA macht nur Sinn, wenn das RootCert einige 20 oder 30 Jahre gültig ist. Wer der Sponsoren stellt so lange seine Unterstützung sicher ?. Selbst große Firmen wie Novell haben in 20 Jahren sich sehr stark verändert. Hoffen wir das Beste.
  • Integrität
    Ich sehe schon ein Risiko, dass irgendwann ein Trojaner oder modifiziertes Paket nicht nur lokal den Key erstellt und automatisch signieren lässt, sondern den PrivateKey auch extern "sichert". Technisch kann man das kaum verhindern, denn der Prozess darf ja auf das Internet zugreifen und macht sogar ein Autoenrollment. Welcher Admin hat schon die Zeit das Paket darauf zu untersuchen.

Insofern ist der Ansatz interessant aber es gibt noch einige Hindernisse im Weg.

Andere Option: Bestehende PKIs ?

Der Ansatz könnte aber ein Nachdenken bei anderen Zertifizierungsstellen auslösen. Bislang ist deren Enrollment-Prozess zwar technisch einfach für einen versierten Administrator aber für die Masse doch noch nicht geeignet. Dabei geht es gar nicht um das "Bezahlen", sondern die ganze Thematik ist noch nicht "Plug an Play".

Dass es anders geht, hat Microsoft z.B. mit dem Windows Home Server damals schon gezeigt. Als ich meinen Acer H340 damals installiert und für "Remote Access" konfiguriert habe, hat der Server ohne eine Rückfrage ein öffentliches Zertifikat von GoDaddy bezogen. Da muss es also eine Partnerschaft zwischen Microsoft und GoDaddy gegeben haben, dass ich für <name>.homeserver.com ein Zertifikat bekommen habe.

Es sollte für die bekannten großen Zertifizierungsstellen ein leichtes sein, den gleichen Ausstellungsprozess wie "LetsEncrypt" nachzubauen und damit die Ausstellung und Installation von Zertifikaten zu erleichtern. Sie haben zudem den Vorteil, dass die RootCA schon als Trusted bei vielen Clients vorhanden ist. Dann muss nur noch eine Lösung für die monetäre Seite gefunden werden. Firmen wie Startcom stellen SingleName-Zertifikate kostenfrei aus. Eine CA könnte ja diese "Einfachzertifikate" quasi kostenfrei machen und SAN-Zertifikate, EV-Zertifikate etc. auspreisen. Oder der Preis wird dann durch die Masse so viel günstiger, dass sich die Frage nicht mehr stellt.

Die meisten Hoster rufen Ende 2014 immer noch Preise zwischen 60-240 Euro für die Einrichtung von SSL auf einer Webseite auf. Das ist viel Geld für eine "private Webseite".

Anderer Weg 3: Web Hosting Provider und SSL Included

Die Hoster könnten aber die zweite aktive Komponente in der Umgebung werden. Sie haben heute schon eine Kundenbeziehung samt Abrechnung und Provisioning. Hier könnten die Hoster den Preis sicher reduzieren, wenn SSL einfach "Standard" wird. Anstatt immer mehr Gigabyte Webspace und Postfächer zu addieren, die eh kleiner braucht ist vielleicht "SSL Included" das nächste Entscheidungskriterium für Kunden. Das Zertifikat kann ja von einer IssuingCA des Hosters sein, die ihrerseits von einer öffentlichen CA ausgestellt wird. So kann der Hoster den Kunden auch binden.

Anderer Weg 4: DNSSEC, DANE und Provider

Eine zweite Option eröffnet sich in Zukunft, wenn jeder einfach "Selbstzertifikate" verwenden kann und die Validierung über eine Veröffentlichung des Zertifikats-Eintrags im DNS erfolgt. Entsprechende Clients sind Ende 2014 noch rar, aber könnten bald zum Standard gehören. Natürlich muss dazu auch DNSSEC aktiv sein. Aber hier gibt es schon die ersten Provider, die dies sehr einfach anbieten (z.B.: ovh.de).

Diese Lösung reduziert die Abhängigkeit von der Zertifizierungsstelle, die ja auch "fremd" kontrolliert sein kann, sei es durch Fehler im Prozess oder entsprechende staatliche Stellen, die ein Zertifikat auf einen fremden Namen bekommen um als "Man in the Middle" die Verbindung zu entschlüsseln. Allerdings dauert es auch hier, bis die Clients und die DNS-Infrastruktur dies unterstützt.

Fazit

Dass sich ein paar Firmengrößen dazu durchringen eine "LetsEncrypt"-Aktion zu starten ist nicht überraschend. Schließlich lässt sich das bei der Werbung wunderbar positiv verwenden. Allerdings muss die Zeit zeigen, ob die gestartete Kampagne auch ein Erfolgsmodell wird. Dazu gibt es doch einige Hürden und Knackpunkte.

In den nächten 2-4 Jahren erwarte ich, dass öffentliche Seiten auch weiterhin Zertifikate von bekannten RootCAs kaufen, dass private Personen mit StartCOM oder SelfSigned-Zertifikaten arbeiten. Ich hoffe, dass das Ausrollen eines einfachen Zertifikats für Privatpersonen so einfach wird, wie damals beim HomeServer und die Webhoster ihre SSL-Strategien überdenken.

Weitere Links