[geklärt] MITM bei LetsEncrypt?

[Lohengrin]

Es signiert dir dein Zertifikat, wenn du’s für eine Domain ausgestellt hast, die auf eine Maschine zeigt, auf der du Root-Rechte hast (sprich: Port 443 kontrollierst).

Wie kann dabei ein Man-in-the-Middle verhindert werden?

[DeletedUserReAsG]

Wie sollte MITM in dem Fall ablaufen? Die einzige Möglichkeit wäre, wenn ein Angreifer LetsEncrypt dazu bringen könnte, ihm ein Zertifikat für deine Domain zu signieren. Dann könnte er sich mit dem Zertifikat und dem dazugehörigen Schlüssel als du ausgeben – vorausgesetzt, er kann das DNS auch weiterhin so manipulieren, dass die Domain auf eine von ihm kontrollierte Kiste zeigt. Dann hast du aber ganz andere Probleme ….

Oder meinst du, LetsEncrypt könnte sich in die Mitte setzen? Die bekommen nur ein Certificate Signing Request von dir, und und signieren damit dein Zertifikat mit ihrem Schlüssel. Um sich in die Mitte setzen zu können, müssten sie deinen Schlüssel haben – haben sie aber nicht. Oder meinst du, sie könnten sich selbst ’nen Schlüssel basteln und das Zertifikat für deine Domain signieren und sich damit in die Mitte setzen? Dazu müssten sie wieder das DNS unter Kontrolle haben, was halt auf ganz andere Probleme hindeuten würde […].

Edit, aus‘m anderen Thread:

Das behaupten sie. Es soll glauben wer will. Ich tue es nicht.

An welcher Stelle gibst du ihnen denn deine persönlichen Daten, den Schlüssel oder Geld? Das hat nix mit Behauptungen und Glauben zu tun: der Client ist Open Source, da kann man recht genau nachschauen, was der macht. Der ist auch nicht so komplex, dass es keiner getan hätte, oder keiner verstehen könnte. Und wenn einem das Ding immer noch zu bloatig ist, oder man es nicht versteht, kann man den ganzen Prozess manuell durchführen, und spätestens dann sollte man schon wissen, was für Daten man denn selbst rausgegeben hat. Darunter sind halt weder persönliche Daten, noch ‘ne Einzugsermächtigung für’s Lastschriftverfahren, noch der private Schlüssel deines Servers.

[bluestar]

Aus einem anderen Thread

LetsEncrypt habe ich noch nie benutzt.

Wenn du es noch nie benutzt hast, wie willst du da eine fundierte, vor allem technische, Meinung zu LetsEncrypt haben?

Das MITM Problem sehe ich bei LetsEncrypt auch nicht als gegeben, du brauchst die Kontrolle über Port 80 und 443 auf dem Zielsystem.

Deine DNS-Zone kannst du ja zur Steigerung der Sicherheit mit DNSSEC absichern.

[wanne]

Das MITM Problem sehe ich bei LetsEncrypt auch nicht als gegeben, du brauchst die Kontrolle über Port 80 und 443 auf dem Zielsystem.

Oder einen Spaten irgend wo auf dem Weg zwichen LetsEncrypt und dem Zielsystem.
LetsEncrypt hat nicht die geringste Möglichkeit festzustellen ob sie mit dem Zielsystem oder irgend einer Box auf dem Weg dahin reden. Die kann ja genauso auf Port 80 und 443 Reagieren.
Nein. Seit LetsEncrypt schützt TLS nicht mehr gegen MITM-Angriffe. PUNKT. So schön das alle finden, dass jetzt alle Crypto machen, es ist jetzt weitestgehend nutzlos. Jedes Angriffsszenario, bei dem x509 nötig wäre kannst du jetzt auch den passenden MITM Angriff gegen LetsEncrypt fahren.
Den einzigen Schutz den sie bieten, ist dass der Angriff nicht zuverlässig ist. Mozilla halt ne Menge Server möglichst über die Welt verstreut haben und so nicht vorhersehbar ist, welche Route tatsächlich genutzt wird. (Und du somit nicht weiß, welche Leitung er anzapfen muss.) Bei derzeitiger Zentralisierung des Internets dürfte das aber ein schwacher Trost sein.
Gibt für die meisten deutschen Systeme praktisch keine Route, die nicht über Frankfurt läuft. Wenn jemand da gräbt, kann er problemlos gegen alle deutschen System MITM fahren.
Deswegen hatten sie ja ursprünglich mal HPKP eingeführt (und dann wieder abgeschafft, weil zu kompliziert).

[wanne]

Um das nochmal zu verdeutlichen

du brauchst die Kontrolle über Port 80 und 443

Das ist die Definition von einem MITM-Angriff. Natürlich hat der Angreifer Kontrolle über die Ports sonst bräuchtest du ja keine Public-Key Kryptografie.

Dann hast du aber ganz andere Probleme ….

Das war genau das wogegen TLS schützen sollte.
Für alle anderen Szenarien brauchst du kein TLS und seine Zertifkate sondern könntest um Größenordnungen einfachere Crypto nehmen.,,

[bluestar]

Nein. Seit LetsEncrypt schützt TLS nicht mehr gegen MITM-Angriffe. PUNKT.

Sofern du konsequent auf DNSSEC, eigene DNS-Server und LetsEncrypt über DNS-Challenges nutzt, sehe ich keinen Angriffsvektor für MITM.

[Lohengrin]

Wie sollte MITM in dem Fall ablaufen? Die einzige Möglichkeit wäre, wenn ein Angreifer LetsEncrypt dazu bringen könnte, ihm ein Zertifikat für deine Domain zu signieren.

Das Szenario aus dem ursprünglichen Thread. IMAP-Server bei mir zu Hause, DynDNS, und dann ein Internetserviceprovider. Beim Internetserviceprovider könnte der Man-in-the-Middle sitzen. Der hat die IP-Nummer, auf die das DynDNS verweist. Der kann sich von LetsEncrypt so ein Zertifikat holen.
Dann kommt mein naiver Benutzer, macht IMAP mit TLS zu dem Rechner bei mir zu Hause, und der Man-in-the-Mittel hat ihn.

Edit, aus‘m anderen Thread:

Das behaupten sie. Es soll glauben wer will. Ich tue es nicht.

An welcher Stelle gibst du ihnen denn deine persönlichen Daten, den Schlüssel oder Geld?

(Bitte kopiere das ganze quote-Tag vom anderen Thread! Dann kann man durch Klick dort hinkommen.)
Wenn sie mit dem Man-in-the-Middle zusammenarbeiten, haben sie meine Daten. Mglw bekommen sie Geld nicht von mir, sondern von dem Man-in-the-Middle.
Weiß hier jemand, wer LetsEncrypt finanziert? Ich glaube nicht, dass die nur von Spenden von Benutzern leben.

Aus einem anderen Thread

LetsEncrypt habe ich noch nie benutzt.

Wenn du es noch nie benutzt hast, wie willst du da eine fundierte, vor allem technische, Meinung zu LetsEncrypt haben?

Wenn ich eine fundierte Meinung dazu hätte, dann würde ich nicht hier im Forum fragen. Seltsames Argument. Sind wir hier bei Jeopardy?
Ich habe es bisher noch nie benutzt, weil ich es nicht gebraucht habe, weil ich mir meine Zertifikate selber gebraten habe.

LetsEncrypt hat nicht die geringste Möglichkeit festzustellen ob sie mit dem Zielsystem oder irgend einer Box auf dem Weg dahin reden.

Genau das war meine Befürchtung.
Ich formuliere das aber anders. LetsEncrypt braucht gar nichts festzustellen. Die zertifizieren den, der drangeht. Seine Identität ist "der ist da drangeganen". Das ist dann per Definition das Zielsystem.

[DeletedUserReAsG]

Ich sag’s mal so: wenn du alle(!) CAs auf allen(!) Systemen, die du nutzt, löschst, und nur deine eigene hinterlegst, dann kannst du sicherer sein, dass sich kein anderer unbemerkt ‘n signiertes Zertifikat für deine Domain gebaut hat, und sich als du ausgeben kann. Das hat nix damit zu tun, ob du LE nun nutzt, oder nicht. Wenn du denen unterstellst, sich für deine Seite ’n Zert zu bauen und sich damit zwischen den User und deinen Server zu klinken, könnten sie das ansonsten auch, ohne dass du dein Zertifikat bei denen signieren lässt. Gab in der Vergangenheit durchaus schon Fälle, in denen CAs solche Zertifikate signiert haben – das war allerdings nicht LE.

Diese Befürchtung ist also eher kein Punkt gegen die Nutzung von LE, sondern gegen die Existenz von TLS in seiner heutigen Form insgesamt. Das führt dann im Grunde zu folgenden Optionen, wenn du den vielen etablierten/hinterlegten CAs (zu denen ja mittlerweile auch LE gehört) die Möglichkeit nehmen willst, sich einfach ’n Cert für deine Domain auszustellen: a) du nutzt gar keine Verschlüsselung mehr. Der Sicherheitsgewinn dürfte fragwürdig sein. b) du schmeißt alle CAs aus deinen Clients (auf allen Geräten), und hinterlegst an deren Stelle ausschließlich deine Eigene. Dürfte nicht so praktisch sein, wenn man zu was Anderem, als zu seinen eigenen Kisten verbindet, oder jemand Anderes auf die angebotenen Dienste zugreifen soll (was typisch für Webserver wäre).

Abgesehen davon: Zertifikate und Schlüssel haben weiterhin Fingerprints, so dass man einen MITM-Versuch clientseitig wahrscheinlich erkennen könnte, wenn man drauf achtet. Auch serverseitig gäbe es die eine oder andere Möglichkeit zu erkennen, ob jemand zwischen dem legitimen Client und dem Server sitzt.

Zusammengefasst: jede der vielen in den Clients hinterlegten CAs wäre in der Lage, sich ein Zertifikat für eine gegebene Domain auszustellen und zu signieren, und sich fortan zwischen Client und deinen Server zu hängen – ohne, dass du selbst dein eigentliches Zertifikat bei ihr signieren ließest. Warum ist nun genau LE, der Laden, der von allen hinterlegten CAs das höchste Maß an Transparenz aufweist, ein Problem in deinen Augen?

[habakug]

Hallo,

LE verwendet domain validated certificate (DV) [1], hier [2] beschreibt LE das selbst.
Es gibt auch Extended Validation Certificate (EV) [3], die "eigentlich" in den Browsern mit einem grünen Schloss gekennzeichnet sind. DVs sollen "eigentlich" mit einem grauen Schloss gekenzeichnet sein, die sind aber auch irgendwie grün geworden .
Es ist einem MITM theoretisch möglich für eine Domain ein Zertifikat zu erstellen, wenn er Ports kontrollieren kann. Dennoch kann er nicht an den Private Key des Servers gelangen und "nur" eigenen Content unter dem Zertifikat ausliefern. Das Mittel der Wahl ist hier "Online Certificate Status Protocol stapling (OCSP)" [4].

Gruss, habakug

[1] https://en.wikipedia.org/wiki/Domain-va ... ertificate
[2] https://letsencrypt.org/how-it-works/
[3] https://en.wikipedia.org/wiki/Extended_ ... ertificate
[4] https://de.wikipedia.org/wiki/Online_Ce ... l_stapling

[wanne]

Dennoch kann er nicht an den Private Key des Servers gelangen und "nur" eigenen Content unter dem Zertifikat ausliefern. Das Mittel der Wahl ist hier "Online Certificate Status Protocol stapling (OCSP)" [4].

Der Angreifer ist danach der einziger Besitzer des privaten Schlüssels. (Und kann antürlich auch den (modifizierten) Content des originalen Servers ausliefern. OCSP hilft da wenig. Der Server weiß ja nicht, dass er einen veralteten priaten Key besitzt.)

Zertifikate und Schlüssel haben weiterhin Fingerprints, so dass man einen MITM-Versuch clientseitig wahrscheinlich erkennen könnte

Der weg wie Fingerprints überprüft werden ist nunmal über die CA. Und die sagt halt einfach fälschlicherwiese, dass der korrekt wäre.

Warum ist nun genau LE, der Laden, der von allen hinterlegten CAs das höchste Maß an Transparenz aufweist, ein Problem in deinen Augen?

Weil er zu 100% transparent sagt, dass er seine Aufgabe vollständig nicht wahrnimmt. Der einzige Grund für CAs war MITM-Angriffe zu unterbinden. Sonst könnte man einfach auf die Signierung verzichten. Und genau diesen Angriff unterbindet Mozilla nicht. Die CA ist vollständig nutzlos.
Es gibt einfach keinen Angriff, den LetsEncrypt unterbindet. Alles was sie mache ist, die Warnungen vom Firefox zu unterbinden.
Vor LetsEncrypt hast du wenigstens einen bankaccount unter falschem Namen gebraucht. Das war nicht schwer, aber es war eine Hürde. Jetzt ist diese letzte Hürde gefallen.

Sofern du konsequent auf DNSSEC, eigene DNS-Server und LetsEncrypt über DNS-Challenges nutzt, sehe ich keinen Angriffsvektor für MITM.

Der MITM ignoriert DNSSEC und DNS-Challenges und holt sich sein Zertifikat einfach über HTTP. Würde LetsEncrypt konsequent keine Zertifkate über http ausstellen, wäre das Verfahren sicher.
Dann könntest du aber auch gleich DANE machen. LetsEncrypt ist da nur ein weiterer unnötiger Angriffspunkt.
Aber solange LetsEncrypt HTTP-Challanges zulässt, ist jeder Browser (und damit jeder Server) der LetsEncrypt akzeptiert anfällig.

[bluestar]

Sofern du konsequent auf DNSSEC, eigene DNS-Server und LetsEncrypt über DNS-Challenges nutzt, sehe ich keinen Angriffsvektor für MITM.

Der MITM ignoriert DNSSEC und DNS-Challenges und holt sich sein Zertifikat einfach über HTTP. Würde LetsEncrypt konsequent keine Zertifkate über http ausstellen, wäre das Verfahren sicher.

Das LetsEncrypt lässt kein HTTP-Challenge zu, sofern du erst einmal auf dem DNS-Challenges bist... Da musst du 3 Monate warten, in der Zeit kein DNS-Challenge kommen darf um danach wieder mit HTTP-Challenge anzufagen.

Aber solange LetsEncrypt HTTP-Challanges zulässt, ist jeder Browser (und damit jeder Server) der LetsEncrypt akzeptiert anfällig.

Bei den Wildcard-Zertifikaten hat LetsEncrypt dementsprechend schon reagiert, die bekommst du nur über ein DNS-Challenge.

[DeletedUserReAsG]

Der weg wie Fingerprints überprüft werden ist nunmal über die CA.

Das richtige Zertifikat liegt auf dem Server vor, man kann sich dort dessen Fingerabdruck anzeigen lassen. Wenn sich der von dem unterscheidet, was der Browser als Fingerprint anzeigt, ist halt was im Übertragungsweg, das da nicht hingehört.

[wanne]

Das LetsEncrypt lässt kein HTTP-Challenge zu, sofern du erst einmal auf dem DNS-Challenges bist... Da musst du 3 Monate warten, in der Zeit kein DNS-Challenge kommen darf um danach wieder mit HTTP-Challenge anzufagen.

Das war mir so nicht bekannt. Danke für die Info. Damit sind Seiten, die DNSSEC und DNS challenge validation machen wirklich sicher.

Ich ahne schon worauf das jn ein paar Jahren raus läuft: Ich darf bei jeder CA Opt Out aus deren unsicheren Verfahren machen.

[Lohengrin]

Das LetsEncrypt lässt kein HTTP-Challenge zu, sofern du erst einmal auf dem DNS-Challenges bist... Da musst du 3 Monate warten, in der Zeit kein DNS-Challenge kommen darf um danach wieder mit HTTP-Challenge anzufagen.

Ah! Jetzt wird mir einiges klarer!
Ich muss zeigen, dass ich meinen DNS-Eintrag verändern kann, bevor LetsEncrypt mir die Verbindung zwischen meinem öffentlichen Schlüssel und meinem Domainnamen bestätigt. Das kann der beim ISP oder der in meinem DSL-Modem nicht. Also kriegt der kein Zertifikat auf meine Domain.
Habe ich das richtig verstanden?

Geht das auch mit DynDNS? Kann ich da in meinem DNS-Eintrag das geforderte Challenge erfüllen?
Das nächste Problem wäre dann, dass in der Kette, die da brechen kann, mein Login bei meinem DynDNS-Anbieter mit drinhängt.
Aber das ist alles verglichen mit meiner ersten Befürchtung Kleinkram.

[Lohengrin]

Abgesehen davon: Zertifikate und Schlüssel haben weiterhin Fingerprints, so dass man einen MITM-Versuch clientseitig wahrscheinlich erkennen könnte, wenn man drauf achtet. Auch serverseitig gäbe es die eine oder andere Möglichkeit zu erkennen, ob jemand zwischen dem legitimen Client und dem Server sitzt.

So würde ich es machen. Hoffentlich kriegt der Benutzer mit, wenn da ein neues Zertifikat ist. Wenn ich meinem Benutzer sage, dass dann, wenn sowas ist, er bei mir Alarm schlagen muss, ist für mich alles ok.
Sollte ich mein Zertifikat ändern, dann teile ich das meinem Benutzer mit, nenne ihm den neuen Fingerprint - unterschrieben mit OpenPGP. Mein Benutzer vertraut meinem OpenPGP-Schlüssel, zB weil er den selbst unterschrieben hat.

Zusammengefasst: jede der vielen in den Clients hinterlegten CAs wäre in der Lage, sich ein Zertifikat für eine gegebene Domain auszustellen und zu signieren, und sich fortan zwischen Client und deinen Server zu hängen – ohne, dass du selbst dein eigentliches Zertifikat bei ihr signieren ließest.

Richtig. Das meinte ich, als ich schrieb, dass TLS fundamental faul sei. Ich benutze es nur, weil die gängigen Emailprogramme damit klarkommen.

Warum ist nun genau LE, der Laden, der von allen hinterlegten CAs das höchste Maß an Transparenz aufweist, ein Problem in deinen Augen?

Wenn es dem, der in meinem DSL-Router lauert, nicht möglich ist, ein eigenes Zertifikat von LetsEncrypt auf meine Domain zu bekommen, bin ich beruhigt. Dann ist LetsEncrypt nicht besser und nicht schlechter als die anderen auch.

[bluestar]

Ah! Jetzt wird mir einiges klarer!
Ich muss zeigen, dass ich meinen DNS-Eintrag verändern kann, bevor LetsEncrypt mir die Verbindung zwischen meinem öffentlichen Schlüssel und meinem Domainnamen bestätigt. Das kann der beim ISP oder der in meinem DSL-Modem nicht. Also kriegt der kein Zertifikat auf meine Domain.
Habe ich das richtig verstanden?

Ja das hast du richtig verstanden.

Geht das auch mit DynDNS? Kann ich da in meinem DNS-Eintrag das geforderte Challenge erfüllen?

Da müsstest du wohl mal die gängigen DynDNS-Anbieter durchtesten...

Ich hab feste IPs und eine DNS-Server und für Bekannte auch nen eigenen DynDNS-Service

[Lohengrin]

Ja das hast du richtig verstanden.

Danke! Damit ist meine ursprüngliche Frage geklärt.

[Lohengrin]

Damit sind Seiten, die DNSSEC und DNS challenge validation machen wirklich sicher.

Die Formulierung sind wirklich sicher ist etwas Absolutes. Es ist im Rahmen der Möglichkeiten von X.509 sinnvoll.
Das Problem ist die Identität, und das ist ein X.509-Problem. Die Autorität bestätigt die Verbindung zwischen der Identität und dem öffentlichen Schlüssel. Eine Autorität, die einen Reisepass überprüft, verlässt sich auf die Behörde, die den Pass ausstellt. Eine Autorität, die die Fähigkeit den DNS-Eintrag zu verändern überprüft, verlässt sich auf DNS.

Inzwischen bin ich der Meinung, dass die Fähigkeit, den DNS-Eintrag zu verändern, als Identität zu nehmen, eine sehr gute Entscheidung ist. Bei TLS geht es letztendlich nur um den DNS-Eintrag. Mir fällt keine bessere Identität für diesen Zweck ein.
Dass diese Autorität lügen kann, dass eine Autorität bei DNSSEC lügen kann, dass es bei DNS, weil es da einen gemeinsamen Namensraum für jeden gibt und die Namen nicht zufällig entstehen, zwangsläufig Namensstreit gibt, ist ein Problem, das nicht im Rahmen von TLS gelöst werden kann. Also sollte man auch nicht den Anschein erwecken, es lösen zu können.

[bluestar]

Dass diese Autorität lügen kann, dass eine Autorität bei DNSSEC lügen kann

Theoretisch kann jede Art von Autorität lügen, bzw. Identitäten fehlerhaft bestätigen.