Bericht Let's Encrypt: Erste Erfahrungen mit dem HTTPS für jedermann

[Claw6]

@Cool Master

Dir seien alle Vorträge von Moxie Marlinspike der letzten Jahre zum Thema SSL ans Herz gelegt. Du brauchst da ein wenig Korrektur in deiner Blase.

 

[kling1]

Zudem musst Du Mail empfangen können, die an Deine Domain geschickt wird.

die mail muss nicht nicht an die eigene domain rausgehen.. sondern an irgend eine email adresse.. setze es seit der closed beta ein.. die einrichtug ist sehr einfach.. eine zeile ins terminal tippen und dann noch nginx vhosts confings entsprechend anpassen

 

[dienst]

Sehr verständlich geschriebener Artikel!

 

[fethomm]

die mail muss nicht nicht an die eigene domain rausgehen.. sondern an irgend eine email adresse.. setze es seit der closed beta ein.. die einrichtug ist sehr einfach.. eine zeile ins terminal tippen und dann noch nginx vhosts confings entsprechend anpassen

Ich brauchte das auch nicht, steht aber so als Bedingung in der Doku. Die ist derzeit zwar ausführlich, aber insgesamt nicht ganz auf der Höhe der Zeit.

 

[Homofürst]

die mail muss nicht nicht an die eigene domain rausgehen.. sondern an irgend eine email adresse..

Danke, genau das habe ich mich gefragt.

 

[Qowy]

Gibt es jetzt hier einen Vorteil im Vergleich zu dem free level von startssl.com?

Den client der einrichtet kann man jetzt positiv / negativ sehen.

Für IIS geht das vermutlich sowieso noch nicht oder? Also vermutlich kein Grund für mich zu wechseln.

 

[fethomm]

Gibt es jetzt hier einen Vorteil im Vergleich zu dem free level von startssl.com?

Den client der einrichtet kann man jetzt positiv / negativ sehen.

Für IIS geht das vermutlich sowieso noch nicht oder? Also vermutlich kein Grund für mich zu wechseln.

Es gibt ein Plugin für IIS aus der Community. Kann ich aber nichts zu sagen.

 

[Enigma]

# letsencrypt-auto needs root access to bootstrap OS dependencies, and
# letsencrypt itself needs root access for almost all modes of operation
# The "normal" case is that sudo is used for the steps that need root, but
# this script *can* be run as root (not recommended), or fall back to using
# `su`

Ähhmmm, genau Ich führ doch sowas nicht als root aus! Gehts noch?

 

[Merkuras]

@Enigma Let's Encrypt prüft sozusagen deine Identität darüber, dass du root auf dem Server bist. Nur deswegen funktioniert der "Vertrauensbeweis" technisch überhaupt. Deswegen wirst du das auch niemals nicht als root ausführen können.

 

[DocWindows]

Das worum es bei https /TLS geht ist, das es genau 2 Stellen gibt, an dem man die transportierten Daten im Klartext lesen kann: Sender und Empfänger

Und genau dafür würde ich das auch nehmen. Um Man-in-the-Middle Angriffe zu umschiffen. Dabei muss ich meinem Gegenüber noch lange nicht vertrauen. Ich vertraue nur darauf dass die Kommunikation quasi abhörsicher und integer abläuft. Wenn man Vertrauen als Wort verwenden wollte, könnte man vielleicht von einem Vertrauen auf Serveridentität sprechen, aber eben nicht auf ein Vertrauen auf Betreiberidentität. Wenns darum ginge, würde ich cacert.org bevorzugen. Aber ich sagte ja schon, dass Vertrauen so wie ich es beschreibe wohl gar nicht der Sinn hinter Lets Encrypt ist, sondern einfach nur die verschlüsselte Kommunikation ohne den Trust-Aspekt.

Hab jetzt auch die Konfiguration von Firefox und IE hinbekommen. Beide Browser warnen jetzt vor Seiten die solche Zertifikate nutzen, lassen die Nutzung nach einer Bestätigung aber trotzdem zu.

 

[Barton]

Als wenig-bis-nie Poster muss ich hier auch mal meinen Senf dazugeben:

Egal ob ich die Zertifikate einsetzen werde oder nicht:

Die Artikel von fethomm sind gut geschrieben und sehr lesenswert.
Wie bereits oben erwähnt eine wirkliche Bereicherung von ComputerBase.
Bitte unbedingt weiter so!

P.S.:
Mich interessiert das 100. Update einer Android App oder ein x.x.x.1 Update von IOS nicht.

 

[Cool Master]

Ähhmmm, genau Ich führ doch sowas nicht als root aus! Gehts noch?

Sag ich ja schon seit Seite eins

Ich erstelle lieber ein CSR (was auch nur root machen kann) und sende das an die CA welche mir daraus das Public Zertifikat schickt. Einfacher und sicherer.

 

[Enigma]

Der funktioniert über einen HTTP-Check. Das hat erstmal nichts mit Root-Rechten zu tun. Ich finde es eher grob Fahrlässig einem unbedarften User so eine Empfehlung zu geben. Hier sollte explizit auf die Risiken hingewiesen werden und erstmal eine manuelle Methode (z.B. kopieren einer Hashdatei ins Docroot des VHosts) empfohlen werden.

 

[TrueAzrael]

@fethomm

Also ich vertraue eher denen die Geld damit verdienen wollen. Warum? Na ja die wollen damit Geld machen und ihr essen bezahlen.

Wäre es da nicht das beste jedem der bezahlt blind ein Zertifikat zu signieren?
Mehr signierte Zertifikate = Mehr Geld
Warum also überprüfen wer da den Antrag stellt?
Mir sind da Leute die das aus Überzeugung machen lieber als jene die rein auf Profit aus sind.

Ist aber wohl Geschmackssache und würde nie ein Diskussionsende finden.

 

[Benj]

Also ich muss schon sagen, Ferdinand Thommes macht für mich einen guten Teil der CB-Qualität aus. Die Artikel gehen auch mal in die technischen Linux-Untiefen, während man sonst von Linux abseits von Steammachines eher wenig liest. Weiter so und bitte mehr =D !

Heute Abend wird dann direkt mal getestet, einmalig den cronjob einzurichten ist ja kein Problem =)

/signed

(habe LetsEncrypt auch schon in Verwendung, funktioniert bisweilen hervorragend, allerdings nur auf meinem Unix-Webserver; die Einbindung in diverse Webinterfaces von verschiedenen Programmen unter Windows Server 2012 R2 auf einer Dyndns-Domain will noch nicht so recht klappen, weil der Client irgendwie IIS benötigt)

 

[patrick888]

Evtl. geht es mir da nur so aber ich will nicht das eine Software mir an meiner Server Config etwas dreht.

Ich habe zudem ein Skript für mich geschrieben welches automatisch eine Apache Config erstellt die wie folgt aussieht:

..

Nicht nur nicht an der Config was dreht, auch wenn dort im DocRoot Inhalte angelegt / geändert werden seh ich das serh kritisch.

Ich erstelle lieber ein CSR (was auch nur root machen kann)

Wie kommst du da drauf? Weshalb sollte es mir als Benutzer nicht möglich sein openssl aufzurufen und darüber ein csr zu generieren?

 

[riloka]

Nicht nur nicht an der Config was dreht, auch wenn dort im DocRoot Inhalte angelegt / geändert werden seh ich das serh kritisch.

Das System muss doch irgendwie prüfen dass du befugt bist für diese Domain ein Zertifikat zu erhalten.
Wenn du das automatisch willst muss es eben "Proof/Beweise" dafür in deinem Server hinterlegen.
Dateien mit vorgegebenem Namen, Zertifikate für eine nicht-existierende Subdomain, Einträge im DNS , oder was sonst noch später dazukommt.
Dazu muss eben was geändert werden. Wenn du das nicht willst kannst du es immer noch manuell machen.

 

[Cool Master]

.....
Warum also überprüfen wer da den Antrag stellt?
Mir sind da Leute die das aus Überzeugung machen lieber als jene die rein auf Profit aus sind.

Im Prinzip läuft das ja schon so heute bei einer Domain Validation. Da kann jeder den Antrag stellen solange er eine Mail mit der Domain hat. Deswegen kann man nicht sagen ich Vertraue CA X mehr als Y. Zudem wenn so ein Verhalten heraus kommt gibt es die CA nicht mehr lange bzw. die wird einfach aus den Browsern entfernt.

Wenn man echtes Vertrauen haben will darf man nur noch OU Zertifikate anbieten aber die sind nicht gerade günstig. Je nach CA sind da 4000+ € fällig, und das je Jahr bei drei Jahren Laufzeit sind da also mal eben 12k € weg.

Wie kommst du da drauf? Weshalb sollte es mir als Benutzer nicht möglich sein openssl aufzurufen und darüber ein csr zu generieren?

Zumindest unter Debian ist dies nicht möglich, da man dafür root rechte benötigt. Ich muss aber gestehen ich habe es nich nie versucht da ich mich nur über root anmelde.

 

[berndy2001]

Public Beta ist ab 6 Uhr ABENDS heute

GMT; also 19 Uhr MEZ/CET

 

[fuyuhasugu]

Solange das nicht einfach ein zu setzendes Häkchen beim Provider ist, bleibt das wohl eine Lösung für Nerds. Immerhin etwas, denn selbst für die scheiterte es bisher ja schon an den Kosten.