Let's Encrypt

[rolapp]

Mal nur eine kleine Frage.
Hat schon mal jemand Let'sEncrypt ausprobiert und was haltet ihr davon?

Für die angebotenen class1 Zertifikate finde ich die Möglichkeit nicht schlecht.
Vor allem die Möglichkeit das Zertifikat mit einem Cronjob zu erneuern.
Ich habe mir die Domain von meinem BananaPi mal für das Beta frei schalten lassen.
Zertifikat über letsencrypt-auto beantragt und die Konfiguration automatisch für den Apache erstellen lassen. Auf www.ssllabs.com habe ich jetzt ohne weitere Änderung meinerseits schon mal ein grünes A bekommen.
Was bei mir jetzt nicht funktioniert hat ist die automatische Konfiguration bei zwei vhosts (ipv4 / ipv6) in einer config.
Ok die automatische Konfiguration ist jetzt persönliche Geschmackssache. (kann man über optionen oder config File abstellen)
Ich werde das Projekt jedenfalls mal im Auge behalten.

 

[elias5000]

Im Sinne der "encrypt everything"-Bewegung ist es eine tolle Sache.
Das automatische Konfigurieren ist allerdings eher etwas für Leute, die finden dass es eine valide Installations-Strategie ist, ein Script aus dem Web in eine root-Shell zu pipen.

 

[d4f]

Das automatische Konfigurieren ist allerdings eher etwas für Leute, die finden dass es eine valide Installations-Strategie ist, ein Script aus dem Web in eine root-Shell zu pipen.

Rein objektiv betrachtet ist das genau die Installationsstrategie für die erschlagende Mehrheit an Webhostingprodukten und -erweiterungen. Auf ein weiteres Produkt kommt es dabei nicht mehr an - wobei LetsEncrypt eine deutlich höhere Seriosität aufweisen kann als so manch andere verbreitete "Werkzeuge".
Da Letsencrspt einen offenen Standard (ACME) vorgestellt hat, gibt es aber natürlich mittlerweile auch alternative Clients welche kein root voraussetzen, bspw:
https://github.com/diafygi/letsencrypt-nosudo

und was haltet ihr davon?

Bis darauf dass bislang kein einziger Meilenstein zeitmässig nur halbwegs eingehalten werden konnte, eine geniale Idee. Wir sind dabei als Nebenprojekt LetsEncrypt als Ein/Aus Knöpfchen für alle Webhosting Kunden zu implementieren damit die Kunden nicht mehr SSL als "brauch ich nicht" bei Firmenseiten ansehen.

 

[Joe User]

Alle 60-90 Tage neue Certs und Keys installieren, HPKP und/oder CT konfigurieren und gegebenenfalls auch noch DANE und Co?
Ich bin mir noch unschlüssig ob ich das ganze Projekt in der Form empfehlen würde.

Persönlich werde ich erstmal bei StartSSL bleiben und LetsEncrypt beobachten.

 

[gunnarh]

Du must bei passender Konfiguration weder HPKP noch DANE rekonfigurieren. Einfach neues Zertifikat unter Beibehaltung des RSA-Schlüsselpaares und somit des CSR anfordern, lässt sich freilich automatisieren (und so wird es auch empfohlen).

DANE lässt sich auf den Public Key pinnen. Und HPKP ist per Definition ohnehin kein Zertifikats- sondern PublicKeyPinning.

Details: https://it-sec.ovh/secure-mail
Kapitel 3.1.7 sowie 3.2.1

 

[Joe User]

Es geht ja nicht um mich, ich kann mir dafür selbst Scripte schreiben, sondern um die Idioten, welche die von LetsEncrypt empfohlenen und bereitgestellten "automagischen Tools" verwenden und damit dann auf die Schnauze fallen werden.

Und wenn wozu soll man alte Keys für neue Certs verwenden? Macht wenig Sinn, ebenso wie das theoretisch mögliche Pinning der Intermediate/Root-Keys.

LetsEncrypt ist einfach noch nicht productionready und spätestens für das von Google präferierte Endloslog bei CT sind permanent neu erstellte Certs und damit Logeinträge tödlich.
Auch für das browserinterne Pinning wie es Chrome, Firefox und Edge umgesetzt haben, ist LetsEncrypt kontraproduktiv.

LetsEncrypt wird also das Netz nicht wie versprochen sicherer machen, sondern eher das Gegenteil bewirken...

 

[maltris]

Sicherer als komplett unverschlüsselt wirds allemal.

 

[gunnarh]

Es geht ja nicht um mich, ich kann mir dafür selbst Scripte schreiben

Die "automatischen Tools" unterstützen beides - also jedes mal neues Schlüsselmaterial oder den CSR zu recyclen.

sondern um die Idioten, welche die von LetsEncrypt empfohlenen und bereitgestellten "automagischen Tools" verwenden und damit dann auf die Schnauze fallen werden.

Leute mit wenig KnowHow setzen erfahrungsgemäß weder DANE noch HPKP verwenden - haben also ohnehin keines der von Dir angesprochenen Probleme.

Und wenn wozu soll man alte Keys für neue Certs verwenden?

Warum nicht?
Wenn Dein Schlüsselpaar nicht kompromittiert ist, und die damals verwendete Schlüssellänge noch immer dem Stand der Technik entspricht, dann spricht nichts dagegen. Man stellt ja kein neues Zertifikat aus, weil man inzwischen Sorge hat, dass jemand den PrivateKey geknackt hat - sondern weil das Widerrufen von Zertifikaten in der Praxis ein großes Problem darstellt und man daher eher kurze Laufzeiten wählt um im Falle einer Kompromittierung die Nutzbarkeit des alten Zertifikats zeitlich zu limitieren. Ein neues Schlüsselpaar zu generieren ist nur nötig, wenn man Sorge hat kompromittiert worden zu sein (Heartbleed, Servereinbruch, ...) oder inzwischen zu kurze Schlüssel im Einsatz hat. Selbst der Umstieg von SHA1 auf SHA2 ist ohne Neu-Generierung des Schlüsselpaares möglich, lediglich der CSR ist zu erneuern.

Macht wenig Sinn, ebenso wie das theoretisch mögliche Pinning der Intermediate/Root-Keys.

Doch, macht Sinn.
Auch das Pinning der Intermediate-Zertifikate ist ein bedeutender Schritt, weil man damit 99,5% der "anderen CAs" (und darunter sind wie wir wissen auch CAs mit staatlichem Einfluss etc... die sich gern mal auch "Testzertifikate" ausstellen) ausschließt. Den CA-Anbieter den man wählt zu dem muss man dann halt Vertrauen haben.

LetsEncrypt ist einfach noch nicht productionready

Die sind ja auch nicht in Produktion sondern in einer Beta-Phase.
Aber ich hatte ehrlichgesagt kein Problem, und die von Dir angesprochenen Probleme durch "zu kurze Zertifikatsgültigkeit" sind in Wahrheit keine Probleme, man muss lediglich den Erneuerungsvorgang automatisieren und ihn alle 60 Tage mal aufrufen.

und spätestens für das von Google präferierte Endloslog bei CT sind permanent neu erstellte Certs und damit Logeinträge tödlich.

Hier verstehe ich ehrlichgesagt nicht was Du meinst. Ich nehme an "CT" steht für Certificate Transparancy? Let's Encrypt nimmt daran teil. Wo siehst Du das Problem?

Auch für das browserinterne Pinning wie es Chrome, Firefox und Edge umgesetzt haben, ist LetsEncrypt kontraproduktiv.

Der typtische Let's Encrypt Anwender oder StartSSL.com Anwender spielt aber ohnehin nicht in der Liga um von Mozilla oder Chrome für internes Pinning aufgenommen zu werden. Wer eine WebSite von Weltbekanntheit betreibt wird wohl auch weiterhin auf Schlüsselmaterial in HSM's von vertrauenswürdigen Branchengrößen Gebrauch machen.

LetsEncrypt wird also das Netz nicht wie versprochen sicherer machen, sondern eher das Gegenteil bewirken...

Die Einschätzung teile ich nicht.

 

[killerbees19]

Ist die Verifizierung mittels DNS mittlerweile schon implementiert?
Davon stand zumindestens irgendetwas in den ACME-Spezifikationen.


MfG Christian

 

[[netcup] Felix]

Hallo,


wenn Let's Encrypt sich durchsetzt, wird es vermutlich kostenpflichtige DV-Zertifikate überflüssig machen. Als Provider werden wir darauf reagieren und sämtlichen Kunden kostenlose DV-Zertifikate anbieten (müssen ). Große CAs werden demnächst Flatrates dafür bereitstellen. Erste Angebote liegen uns dafür bereits vor.

Über Let's Encrypt können wir relativ einfach jedem Webhosting-Kunden SSL anbieten. Erste Tests waren hier bereits erfolgreich.

Die Kosten für Webhosting werden dann zumindest im Einkauf teurer werden, denn SSL erfordert auch Rechenlast, die bei großen Mengen von Anfragen nicht unterschätzt werden darf.

Sollten die großen CAs dann auch kostenlos ihre DV-Zertifikate vergeben, würde Let's Encrypt eventuell wieder sterben. Immerhin hat das Projekt dann etwas wesentliches bewegt.


In dem Sinne ein angenehmes Wochenende!


Gruß Felix

 

[d3p]

Die Kosten für Webhosting werden dann zumindest im Einkauf teurer werden, denn SSL erfordert auch Rechenlast, die bei großen Mengen von Anfragen nicht unterschätzt werden darf.

Entschuldigt, dass ich diesen Thread nun "hijacke".

Ist das aber nicht eher nur ein "Mythos" (https://www.maxcdn.com/blog/ssl-performance-myth/) ?
Um ehrlich zu sein, habe ich mich mit dem Thema noch nicht so sehr befasst, würde aber gerne mehr darüber erfahren.

 

[d4f]

Verglichen mit der Rechenlast der meisten Webseitenoperationen ist SSL für normale Webhoster und Serverbetreiber absolut vernachlässigbar. Es lässt sich zwar ausnutzen um dem Server mehr Rechenleistung ab zu verlangen aber selbst ein 0815 Bruteforce auf bspw. Wordpress ist da um Längen schlimmer.
Für latenzkritische Anwendungen und Anbieter mit grösseren Serverzahlen mag es relevant sein, aber für entsprechende Einsatzgebiete gibt es dedizierte Lösung welche den Aufwand optimieren und sogar reduzieren.

Man darf mittlerweile auch nicht überschätzen wieviel SSL "frisst": dank ECC-Standards und Hardwareoptimierung sowie Session caching ist der durchschnittliche Besucher eines durchschnittlichen Servers deutlich rechenaufwendiger was Kompression angeht als was Verschlüsslung betrifft.