News Mozilla: Firefox 50 vertraut Let's Encrypt

[Snowi]

Ich find es ist eine echt positive Entwicklung, und den Zertifikaten wird eigentlich von fast allen Browsern/Geräten vertraut, danke an Identrust.
Wobei, ehrlich gesagt finde ich das Modell der CAs schon lange überfällig. Als ob ich noch irgendeiner CA vertrauen würde.
Ich pinne mir das Cert beim ersten Besuch, wenn es mir bei bestimmten Seiten wichtig ist, gehe ich über verschiedene Verbindungen drauf (TOR, VPN, Öffentliches Wifi, Mobilfunk, ...) und vergleiche die Zertifikate, ob das alles die gleichen sind, oder ob mir eins untergejubelt wurde (MITM).
Aber nur weil da Identrust, Letsencrypt, VeriSign oder sogar Comodo (Bis ich gemerkt habe, was die alles verzapfen pro Jahr, hab ich die eigentlich wegen den niedrigen Preisen gemocht) drauf steht, traue ich dem Braten nicht.

Was ist der Grund/Gründe dafür?

Warum die Gültigkeit 90 Tage ist: https://letsencrypt.org/2015/11/09/why-90-days.html
Die Gründe lassen sich so auch 1zu1 auf 30 Tage anwenden.

Wer kein Englisch kann + meine eigene Meinung:
1. Im Falle, dass der Private-Key des Zertifikats in die falschen Hände gelangt, kann dieser nicht für z.B. 1 Jahr weiter missbraucht werden. Zumindest wenn man es als Admin denn merkt.
Ist in meinen Augen aber nur halb sinnvoll, denn dafür gibt es ja Certifikate Revokes.
Ist aber auch wieder Aufwand & je nach Anbieter kostet das dann sogar noch. Und so lässt man es im schlimmsten Fall einfach auslaufen, wobei revoke in meinen Augen eher angebracht wäre.
2. Wenn die Zertifikate nur 90/30 Tage gültig sind, muss der Ablauf quasi automatisiert werden. Und das hat nur Vorteile.
Wenn ein Admin z.B. 40 Zertifikate zu managen hat, muss dieser alle 40 Zertifikate alle X Jahre manuell erneuern.
Bei 90 Tagen ist da 0 Sinn hinter, bei 30 sowieso nicht. Muss also automatisiert werden, und dadurch entsteht im weiteren Verlauf weniger Aufwand, da man sich eben nicht mehr aktiv drum kümmern muss.

 

[wahlmeister]

@wahlmeister: Autos muss man glaube ich vor Diebstahl schützen, damit nicht unberechtigte Personen zu leicht an ein Auto kommen.

Das ist richtig und kann theoretisch 10€ kosten wenn es jemand der Polizei meldet. Trotzdem kann einen keiner dazu zwingen. Es gibt genug Leute die ihr Auto unverschlossen in der Garage stehen haben, oft Steckt sogar der Schlüssel.

Überraschend finde ich, dass hier in einem IT-Forum so viele Leute Zertifikate mit Verschlüsselung gleichsetzen...

Was ist denn lets encrypt für dich? Das ganze dient dazu das Internet nach und nach komplett auf HTTPS umzustellen.

 

[andr_gin]

Ich sehe das Ganze eher mehr als Notlösung. Theoretisch reicht es kurzfristig Zugang zum Webserver zu bekommen, um sich automatisiert ein Zertifikat ausstellen zu lassen, über das ich dann auf Ewigkeiten eine falsche Identität für Dienste wie Paypal, Online Banking etc. ausstellen lassen kann. Auf der anderen Seite ist der administrative Aufwand für viele Anwendungen immer noch zu groß. Was wir eigentlich bräuchten wäre eine https Light Version, bei der nur verschlüsselt wird aber ohne Zertifikat gearbeitet wird. Für die meisten 0815 Anwendungen reicht das schon aus. Hier geht es nur darum, dass nicht irgendwer mit Wireshark im Hintergrund alle Passwörter mitlesen kann.

 

[riloka]

Von Zugang zu welchem Server sprechen wir hier andr_gin?

Ich sehe bei ACME-Protokoll von LE und den vielen Plugins für Konfigurations-Oberflächen und dem Certbot-Projekt die Ausssage "Ist zu hoher Aufwand" als nichtig an.

Wir haben hier DomainValidierungs Zertifikate, das heisst nur derjenige der das Zertifikat bekommt, hat zugleich Kontrolle über den Webserver und nicht mehr als das.
Wozu Verschlüsselung ohne Zertifikate? Da hast du doch noch weniger Garantien als bei DV.

 

[Pat]

Warum die Gültigkeit 90 Tage ist: https://letsencrypt.org/2015/11/09/why-90-days.html
Die Gründe lassen sich so auch 1zu1 auf 30 Tage anwenden.

Cool vielen Dank!

 

[andr_gin]

Von Zugang zu welchem Server sprechen wir hier andr_gin?

Ich sehe bei ACME-Protokoll von LE und den vielen Plugins für Konfigurations-Oberflächen und dem Certbot-Projekt die Ausssage "Ist zu hoher Aufwand" als nichtig an.

Wir haben hier DomainValidierungs Zertifikate, das heisst nur derjenige der das Zertifikat bekommt, hat zugleich Kontrolle über den Webserver und nicht mehr als das.
Wozu Verschlüsselung ohne Zertifikate? Da hast du doch noch weniger Garantien als bei DV.

1.) So wie ich das verstanden habe muss man zur Authentifizierung lediglich eine Date auf dem Webserver ablegen. Es ist zwar naheliegend, dass man dann auch Eigentümer der Domäne ist, aber ein Beweis ist das nicht. Ein Mitarbeiter des Providers hätte genauso Zugriff. Für 99% der Server ist dieses Maß an Sicherheit ausreichend, aber eben nicht für alle. Ich warte nur darauf bis sich einer der Paypal Mitarbeiter heimlich ein Zertifikat ausstellt und dann auf dm Schwarzmarkt verdreht und jeder Browser die gefälschte Paypal.com Webseite als echt erachtet.

2.) Verschlüsselung ohne Zertifikate hat den Sinn, dass die ganzen Wald und Wiesenserver einmal so sicher sind, dass man nicht einfach per Wireshark mitlesen kann, ein Administrator jedoch sehr wohl noch eine Firewall dazwischn schalten kann ohne dass auf allen Clients Zertifikate nachinstalliert werden müssen.

 

[birday]

Revocation lists sind teuer und unpraktisch. Daher sind kurze Laufzeiten fuer gratis certs sinnvoll. Und tls ohne trusted ca cert ist nahezu sinnlos, da man verwundbar gegen mitm attacks bleibt.

 

[fdsonne]

Ich warte nur darauf bis sich einer der Paypal Mitarbeiter heimlich ein Zertifikat ausstellt und dann auf dm Schwarzmarkt verdreht und jeder Browser die gefälschte Paypal.com Webseite als echt erachtet.

Und das bringt ihm dann genau was?
Das Zertifikat ohne private Key ist effektiv nutzlos.
Den private Key kann/sollte/muss man dediziert schützen -> wer das nicht macht? Selbst schuld.
Selbst WENN das CERT File irgendwo im Netz auftaucht und jemand den passenden Key dafür noch mit findet, ohne Admin Access auf die Nameserver, wo paypal.com gehostet wird, lässt sich da auch nix flächendeckend drehen.
-> einziger Angriffsvektor in dem Fall wäre, es spielt einer mitm zwischen einem Client, der Paypal nutzen will und dem Paypal Servern... DANN kann sich der Mittelsmann durch manipulation der DNS Anfragen auf www.paypal.com auf einen Fremdserver umleiten, der dann eben besagtes, gestohlenes Zertifikat, samt private Key einsetzt.
Wann trifft das im Endeffekt wirklich zu bzw. wie warscheinlich ist genau so ein Umstand??

Mal davon ab, paypal.com ist ein ziemlich blödes Beispiel. Denn die verwenden EV-Zertifikate. Taucht also bei dir im Browser oben nicht "PayPal, Inc" irgendwo in der Nähe der URL auf, (meist grün hinterlegt), dann ist das schonmal das erste Indiz dafür, dass da was faul ist. (bspw. wenn man über einen Proxy mit SSL scanning surft)

Der nächste Punkt ist, normal werden keine Wildcard Zertifikate genutzt. Sondern die URLs hart ins Zertifikat gebrannt. Bei PayPal steht da www.paypal.com drin. Das Zertifikat wird also NUR auf www.paypal.com überhaupt ohne Warnung reagieren. Wie oben erwähnt, ohne gezielte DNS Manipulation auf genau diesen Eintrag kommst du da nicht weit. Und wenn du DNS soweit umbiegen kannst -> ja dann öffnen sich ganz andere Vektoren

2.) Verschlüsselung ohne Zertifikate hat den Sinn, dass die ganzen Wald und Wiesenserver einmal so sicher sind, dass man nicht einfach per Wireshark mitlesen kann, ein Administrator jedoch sehr wohl noch eine Firewall dazwischn schalten kann ohne dass auf allen Clients Zertifikate nachinstalliert werden müssen.

Da hast du offenbar was grundlegendes nicht verstanden...
Das Zertifikat ist kein Zettel, den du dir in den Schrank legst, vereinfacht ausgedrückt ist es einfach nur ein Schlüssel. Wie schließt du ein Schloss ab ohne einen Schlüssel?
Im Endeffekt geht es einfach nur darum, dass durch das Zertifikat die Authentität der (in dem Fall) Domain gewährleistet ist. Dass das Thema krankt, wissen alle mit etwas nachdenken. Aber für den Regelfall ist es ein besserer Schutz als gar Keiner
-> nur der Betreiber der Site sollte den private Key besitzen.
-> nur mit dem private Key kannst du bei der angebotenen Domain mit diesem Zertifikat verschlüsseln.
Der Sinn dahinter bleibt schlicht und einfach, dass der Nutzer sich sicher sein soll, dass der Betreiber auch wirklich der Betreiber ist...

Ergänzung (7. August 2016)

Ist in meinen Augen aber nur halb sinnvoll, denn dafür gibt es ja Certifikate Revokes.

CRLs haben einen gewaltigen Pferdefuß -> es ist kein Zwang vorhanden, diese abzufragen. Kann/will/darf dein Client die CRL nicht nutzen, dann kann/wird/will er möglicherweise dem zurückgezogenen Zertifikat trotzdem vertrauen.
Desweiteren haben CRLs eine Gültigkeitsdauer, die bei so manchem Client schlicht auch als Cache missbraucht wird -> meint dabei, ist die CRL einmal abgerufen, wird diese solange aus dem Cache bedient, wie sie gültig ist. -> ohne dass diese neu angefragt wird. Auch das ist kreuzgefährlich, da zurückgerufene Zertifikate trotz Revokes eben teils erst Stunden oder gar Tage bei den Clients ankommen.

 

[Chriz]

-> einziger Angriffsvektor in dem Fall wäre, es spielt einer mitm zwischen einem Client, der Paypal nutzen will und dem Paypal Servern... DANN kann sich der Mittelsmann durch manipulation der DNS Anfragen auf www.paypal.com auf einen Fremdserver umleiten, der dann eben besagtes, gestohlenes Zertifikat, samt private Key einsetzt.
Wann trifft das im Endeffekt wirklich zu bzw. wie warscheinlich ist genau so ein Umstand??

Nicht ganz, der größere Angriffspunkt, und vermutlich auch der wahrscheinlichste, ist der Root-CA selbst!
kennst Du "Honest Achmed's Used Cars"?

Man erinnert sich noch an die kompromittierung der googel.com domain (sämtlicher subdomains!) bei Diginotar in den NL.
Damals (ich glaub 2012) mussten ALLE browser aktualisiert werden. Bis zum vollständigen update vergingen Monate...

 

[Der-Orden-Xar]

2.) Verschlüsselung ohne Zertifikate hat den Sinn, dass die ganzen Wald und Wiesenserver einmal so sicher sind, dass man nicht einfach per Wireshark mitlesen kann, ein Administrator jedoch sehr wohl noch eine Firewall dazwischn schalten kann ohne dass auf allen Clients Zertifikate nachinstalliert werden müssen.

Und da lieferst du gleich den Grund mit, warum die Idee direkt auf den Restmüll kann.
Wenn ich in einem Fremden (offenen oder Teiloffenen) Netz unterwegs bin, z.B. Freifunk oder ein Hotel-WLAN, möchte ich eben nicht, dass jeder Depp, der sich Admin des Netzes nennt da irgendwas an der TLS-Verbindung manipulieren kann.