Frage:
Was macht Let's Encrypt sicher?
user253751
2015-05-04 12:49:51 UTC
view on stackexchange narkive permalink

Let's Encrypt ist eine Initiative der Electronic Frontier Foundation (EFF), von Mozilla, Cisco, Akamai, IdenTrust und Forschern der University of Michigan, die darauf abzielt, jedem Domaininhaber automatisch einen anerkannten Namen zu geben Zertifikat, das für TLS verwendet werden kann.

Um zu beweisen, dass Sie eine Domain besitzen, müssen Sie eine Datei mit bestimmten (zufällig generierten) Inhalten unter einer bestimmten (zufällig generierten) URL in dieser Domain installieren. Der Let's Encrypt-Server überprüft dies, indem er auf die URL zugreift, bevor er das Zertifikat signiert.

Angenommen, ich habe einen Angriff, durch den die Domain awesomebank.example auf meinem Server aufgelöst wird . Angenommen, ich kann auch die Verbindungen einiger Leute zu https: //awesomebank.example/ MITM. TLS soll verhindern, dass ich ihre Kommunikation zum Server sehe oder ändere, ohne erkannt zu werden.

Was hindert mich daran, diesen Angriff auf den Let's Encrypt-Server zu verwenden und ein Zertifikat für awesomebank.example zu erhalten und dann für MITM-Kunden von AwesomeBank verwenden, ohne erkannt zu werden (weil ich ein gültiges Zertifikat habe)? Macht das Vorhandensein einer vollautomatisierten Zertifizierungsstelle das Internet nicht weniger sicher?

"... ein Angriff, durch den die Domain awesomebank.example auf meinem Server aufgelöst wird". Dies wird als DNS-Vergiftung bezeichnet. Wenn Sie dies erreicht haben, warum sollten Sie MITM durchführen? Alle Kundendaten kommen auf Ihren Server. Dann ist das Spiel vorbei. Sie können dies jedoch nur dann problemlos erreichen, wenn Sie den DNS-Registrar von awesomebank.example davon überzeugen, es in Ihre IP-Adresse aufzulösen, oder wenn Sie eine Sicherheitsanfälligkeit in der DNS-Infrastruktur ausnutzen. Auch das kann durch Sperren von DNS-Änderungen gemildert werden.
Viele vorhandene Zertifizierungsstellen sind bereits automatisiert. Sie prüfen nur, ob Sie E-Mails an admin@example.com erhalten können.
Selbst eine DNS-Vergiftung (Cache) funktioniert nur, wenn der Cache verwendet wird. Wenn der Resolver so konzipiert ist, dass er bei jeder Suche speziell der Delegierungskette folgt und dies möglicherweise sogar für alle Alternativen tut und sicherstellt, dass die Antworten übereinstimmen, kann dieser Angriff auf ein hohes Maß an Sicherheit leicht abgewehrt werden. Da das Signieren von Zertifikaten eine relativ niederfrequente Operation ist, würde so etwas andere Systeme nicht wesentlich beeinträchtigen oder die zum Abrufen eines Zertifikats erforderliche Zeit erheblich verlängern.
Dies ist ein Fehler bei dieser gesamten CA-basierten PKI. Alternative Lösungen wie die Verwendung eines Vertrauensnetzes (wie PGP) wären gegen diese Art von Angriff widerstandsfähiger, da Sie im Gegensatz zu einer einzelnen Zertifizierungsstelle mehrere Personen dazu verleiten müssten, Ihrer MITM-Identität zu vertrauen.
@void_in "Alle Kundendaten kommen auf Ihren Server" wäre nur dann der Fall, wenn die Clients tatsächlich die TLS-Verbindung zu Ihrem Server herstellen. Damit dies funktioniert, benötigen Sie (normalerweise) ein gültiges (von einer vertrauenswürdigen Zertifizierungsstelle signiertes) Zertifikat für den Domänennamen. Und um dies zu erreichen, müssen Sie die Zertifizierungsstelle während des Überprüfungsprozesses austricksen.
Das Bild von Let's Encrypt ist angeblich gut.Andernfalls würde diese Frage lauten: "Ist Let's Encrypt vertrauenswürdig?"oder [ähnlich] (https://security.stackexchange.com/questions/127575/is-startssl-com-a-trustworthy-site/127630) ...
[Nicht mehr theoretisch] (https://www.wired.com/2017/04/hackers-hijacked-banks-entire-online-operation)
Gleich nachdem ich den Artikel unter Wired https://goo.gl/zAqLKJ gelesen hatte, landete ich hier. @JimmyJames - Was für ein Zufall, ich wollte den gleichen Kommentar veröffentlichen.
Sechs antworten:
StackzOfZtuff
2015-05-04 14:41:51 UTC
view on stackexchange narkive permalink

Gleiche Sicherheit wie bei anderen DV-Zertifikaten

Was mich daran hindert, diesen Angriff auf den Let's Encrypt-Server zu verwenden, ein Zertifikat für awesomebank.example zu erhalten und es dann für MITM-Kunden von AwesomeBank zu verwenden ohne erkannt zu werden (weil ich ein gültiges Zertifikat habe)?

Nichts. Wenn Sie das Netzwerk besitzen, besitzen Sie das Netzwerk. DV-Zertifikate (siehe unten) basieren auf dem Netzwerk, um den Besitz der Domain nachzuweisen. Es gibt normalerweise keine Out-of-Band-Prüfungen. (Niemand wird Ihr Telefon anrufen, niemand wird Ihren Lichtbildausweis überprüfen, niemand wird Sie an dem Ort besuchen, an dem das Unternehmen registriert ist usw.)

Gibt es keine vollautomatische Zertifizierungsstelle? das Internet weniger sicher machen?

Nein. Gleiche Sicherheitsstufe wie DV-Zertifikate.

Es gibt (derzeit) drei Sicherheitsstufen für x509-Zertifikate:

  • DV, Domain Validation
  • OV , Organisationsvalidierung
  • EV, Erweiterte Validierung

DV ist am billigsten. Dies bedeutet im Grunde "Wenn jemand eine E-Mail an admin@example.com beantworten kann, erhält diese Person ein Zertifikat für example.com" .

Es gibt zusätzliche Prüfungen für OV, EV.

Weitere Informationen zu Zertifikatstypen: GlobalSign.com: Was sind die verschiedenen Arten von SSL-Zertifikaten? (Archiviert hier.) Wikipedia: https://en.wikipedia.org/wiki/Public_key_certificate#Validation_levels Und viele weitere Hintergrundinformationen finden Sie in diesen Folien hier: RSAConference2017, Sitzungs-ID: PDAC-W10, Kirk Hall, 100% verschlüsselt Web - Neue Herausforderungen für TLS

Weiterführende Literatur

(Archiviert hier.)
Netter Blog-Beitrag von GlobalSign CTO Ryan Hurst in seinem privaten Blog.
Er größtenteils macht die gleichen Punkte wie ich. Aber es ist viel tiefer. Und es ist ein bisschen ein Scherz gegen die Rhetorik von TrendMicro gegen Let's-Encrypt.
Beachten Sie, dass TrendMicro und GlobalSign beide SSL-Zertifikate verkaufen und direkte Konkurrenten sind. (Außerdem: Beide sind Mitglieder des CAB-Forums und Mitglieder des CA-Sicherheitsrates.)
  • Update 2018-03-06 : Scott Helme, 06.03.2018, Den Irrtum entlarven, dass bezahlte Zertifikate besser sind als kostenlose Zertifikate, und anderen damit verbundenen Unsinn (Archiviert hier.)
  • Beachten Sie, dass die E-Mail-Prüfung zwar üblich ist, jedoch nicht die einzige automatische Prüfung ist, die verwendet wird. Insbesondere bieten viele vorhandene Zertifizierungsstellen die Option, genau denselben webbasierten Beweis zu erbringen, den Lets Encrypt in ihren Dokumenten beschreibt.
    Ja. Ich bin nur nie auf etwas anderes gestoßen als auf die E-Mail-Version in freier Wildbahn.
    Als ich in einer Webentwicklungsagentur arbeitete, war ich sehr erleichtert, als Comodo anfing, DNS- und HTTP-Verifizierungen anzubieten, da dies bedeutet, dass wir den Vorgang nicht mehr den nicht technischen Mitarbeitern erklären müssen, die Zugriff auf das Konto admin @ e-mail haben. Oder, schlimmer noch, an die IT-Mitarbeiter, die einen solchen Posteingang speziell für diesen Zweck erstellen müssen.
    Während DV und EV Industriestandards sind (standardisiert vom CA / Browser Forum), ist OV meines Wissens nur GlobalSign. Beispielsweise bieten sowohl DigiCert https://www.digicert.com/ssl-certificate.htm als auch Entrust http://www.entrust.net/ssl-certificates.htm EV und eine Reihe eigener Varianten (jedoch nicht OV) an ).
    @MikeOunsworth Obwohl nicht standardisiert, denke ich, dass das breite Konzept von OV als Schritt zwischen DV und EV ziemlich verbreitet ist. siehe z.B. [Comodos Wissensdatenbank] (https://support.comodo.com/index.php?/Default/Knowledgebase/Article/View/312/16/what-is-an-organizationally-validated-certificate).
    "* Macht das Vorhandensein einer vollautomatisierten Zertifizierungsstelle das Internet nicht weniger sicher? * Nein. Gleiches Sicherheitsniveau wie Zertifikate vom Typ DV." Es scheint, dass Let's Encrypt * sicherer * ist, da ein MitM-Angriff damit nicht so einfach wäre wie mit einer zentralisierten Zertifizierungsstelle?
    Steve Jessop
    2015-05-04 22:40:51 UTC
    view on stackexchange narkive permalink

    Ja, das von Ihnen beschriebene Protokoll stellt nur sicher, dass "die Person, die das Telefon bei einer fantastischen Bank abhebt", wenn Sie sie anrufen, dieselbe Person ist, die das Telefon bei einer fantastischen Bank abgenommen hat, als der Let's Encrypt-Server sie anrief. Wenn ich die Möglichkeit habe, Anrufe von Let's Encrypt und von Ihnen an eine fantastische Bank abzufangen, kann ich Sie täuschen.

    Idealerweise möchten Sie, dass TLS Ihnen sagt, dass "die Person, die sie auswählt telefonieren bei awesome bank "wenn Sie sie anrufen, ist tatsächlich ein Mitarbeiter von awesome bank . Dies ist jedoch schwierig zu automatisieren, da Computer nicht einfach herausfinden können, für wen jemand arbeitet, sodass besser validierte Zertifikate mehr kosten. Let's Encrypt macht nichts weniger sicheres als andere Zertifizierungsstellen bereits.

    Man hofft, dass Let's Encrypt versucht, es schwieriger zu machen, ihre Anrufe bei einer fantastischen Bank abzufangen, als Ihre abzufangen. Einige Internetzugangspunkte sind einfacher zu bearbeiten als andere (niedrige Werte für unsichere drahtlose Verbindungen), und das gleichzeitige Durchspielen mehrerer Zugriffspunkte ist schwieriger als nur einer (also wird Let's Encrypt möglicherweise bestätigen, dass dieselbe Datei empfangen wird, wenn sie von vielen verschiedenen heruntergeladen wird Orte auf der Welt, obwohl ich nicht nachgesehen habe, ob sie das für notwendig halten). Mit Ausnahme von Organisationen wie der NSA sind MITM-Angriffe in der Praxis in der Regel lokalisiert und vorübergehend.

    Sie bieten also nur dann ein gewisses Maß an Sicherheit, wenn dies schwieriger ist zu MITM Lassen Sie uns verschlüsseln, als es zu MITM Sie ist. Wir nehmen an, dass es einfacher ist, Ihren Zugang zum Internet zu kontrollieren, als entweder den von Let's Encrypt oder den von Awesome Bank, und deshalb "vertrauen" Sie Let's Encrypt als CA.

    Natürlich keine Davon sind wirklich Telefonanrufe, es sind eingehende Socket-Verbindungen.

    Sie könnten sicherstellen, dass "die Person, die das Telefon bei AwesomeBank abhebt" tatsächlich das Telefon von AwesomeBank verwendet, wenn DNSSEC verwendet wurde.
    @immibis: gut, Sie können "sicher" sein, dass Sie die richtige IP-Adresse mit DNSSEC haben. Ihr Routing könnte immer noch entführt werden. DNNSEC ermöglicht auch zuverlässige CERT-Aufzeichnungen, aber ich bin nicht auf dem neuesten Stand, was Sie davon überzeugt.
    WhiteWinterWolf
    2015-05-04 14:02:34 UTC
    view on stackexchange narkive permalink

    Let's Encrypt wurde entwickelt, um gegen eine Reihe von Angriffen vorzugehen und die Verallgemeinerung der TLS-Nutzung voranzutreiben, um ein global sichereres und privateres Internet zu erhalten. Es zielt genauer darauf ab, technische und finanzielle Einschränkungen zu beseitigen, die einige Webmaster daran hindern könnten, TLS-Zertifikate allgemeiner zu verwenden.

    Als Sicherheitsmaßnahme wird dies jedoch kein Wunderprodukt sein, das alle möglichen Wertpapierprobleme löst und So können Sie Ihre Website als "100% sichere Website!" (Auch wenn einige Websites nicht zögern, solche Briefmarken zu verwenden ...). Sicherheit impliziert die Kombination mehrerer Ebenen, von denen jede für die Bewältigung ihrer eigenen Bedrohungsklasse ausgelegt ist.

    Wenn es einem wirklich gelingt, den Besitz Ihres Domainnamens zu übernehmen, besteht die größte Wahrscheinlichkeit darin, dass Let'sEncrypt verwendet wird Die automatisierte Zertifikatsübermittlung hat in diesem Fall keine größeren Auswirkungen als in einer anderen Situation.

    Zur Erinnerung: Um ein Zertifikat von der klassischen Zertifizierungsstelle zu erhalten, müssen Sie lediglich eine Verwaltungsadresse wie "admin @ example" besitzen. com "und etwas Geld bezahlen. Wenn Sie es schaffen, den Domain-Besitz zu erlangen, können Sie die E-Mail an einen eigenen Mailserver umleiten und somit auch die E-Mail-Adresse Ihrer Wahl besitzen.

    Dies ist keine theoretische Bedrohung. Sie finden hier und einen Artikel, der von jemandem geschrieben wurde, dessen Domain gestohlen wurde, um das Eigentum an seiner E-Mail zu übernehmen. In genau diesem Fall war es für den Zugriff auf die von Drittgesellschaften gesendeten E-Mails zum Zurücksetzen des Passworts vorgesehen. In seiner Position wäre der Angreifer jedoch auch in der Lage gewesen, neue Zertifikate für diese Domain zu generieren und eine Phishing-Site zu erstellen, die als gesichert gilt die Browser.

    Nicht "Eigentümer der Domain werden", aber wenn ich einen DNS-Resolver dazu bringen kann, * vorübergehend * in meine Adresse aufzulösen (z. B. mit Cache-Vergiftung), kann ich mich als nicht temporär als Domain ausgeben.
    Sie müssten nicht nur den Cache des CA-DNS-Resolvers vergiften (ob Let'sEncrypt Ihre Website-Adresse auflöst oder eine andere CA Ihre Mailserver-Adresse auflöst, spielt hier keine Rolle), sondern auch den Cache jedes einzelnen und alle Besucher, die Sie auf Ihre Phishing-Site umleiten möchten, wenn sie zur URL "https: // awesomebank.example" gehen (andernfalls ist das Zertifikat nutzlos, wenn Sie sich nicht als Website ausgeben können). Könnte bis zu einem gewissen Grad als Teil eines sehr gezielten Angriffs machbar sein, bleibt aber eindeutig begrenzt und in großem Maßstab nicht machbar.
    Wenn das MITMing einer Website so schwierig wäre, würden wir sicherlich kein TLS benötigen, um dies zu verhindern?
    MITM ist nicht die einzige Bedrohung, es wird auch abgehört, und die Komplexität aller Bedrohungen hängt direkt von Ihrer Netzwerkposition im Vergleich zum Ziel ab. Wie der Name schon sagt, müssen Sie in der Lage sein, Sie irgendwo "in die Mitte" der Kommunikation zwischen Ihren Zielen zu bringen. Ein externer Endbenutzer (im Gegensatz zu ISP, Regierungsbehörden usw.) ist nicht in der Lage, ein massives MITM durchzuführen. Daher muss er seine Position entweder künstlich verschieben, indem er Zugang zu einigen Maschinen erhält, die bessere MITM-Möglichkeiten bieten. oder verwenden Sie einen anderen Mittelwert, je nachdem, welcher rentabler ist.
    Wenn wir uns nur Gedanken über das Abhören machen würden, würden Browser selbstsignierte Zertifikate akzeptieren.
    @immibis: Selbstsignierte Zertifikate schützen nur vor passiven MITM-Angriffen. Ein aktiver MITM-Angreifer kann ein selbstsigniertes Zertifikat erstellen.
    @Brian Ein aktiver MiTM-Angreifer würde auch Let's Encrypt unterbrechen.
    @Brian Sie sagten "MITM ist nicht die einzige Bedrohung, es gibt auch Abhören". Wenn jedoch das Abhören die Hauptbedrohung wäre, würden Browser selbstsignierte Zertifikate akzeptieren, da das Abhören ohne MITM dann unmöglich ist.
    @user54609: Ein aktiver MiTM-Angreifer hat nur eine Chance (pro Zertifikat), Let's Encrypt zu gefährden, und muss dies tun, indem er die Verbindung zu Let's Encrypt (die von einer vertrauenswürdigen Zertifizierungsstelle signiert ist) gefährdet. Mit einem selbstsignierten Zertifikat ist * jede * Verbindung für aktive MITM-Angriffe anfällig.
    @immibis: Das hat nicht Brian gesagt, und ich habe nie gesagt, dass das Abhören die Hauptbedrohung ist. Ich habe nur gesagt, dass MITM nicht der einzige ist, Abhören ist auch eine Bedrohung. Aus diesem Grund beschränkt sich TLS nicht nur auf die Gewährleistung von Authentifizierung und Integrität, sondern auch auf die Vertraulichkeit. Gehen Sie zu einem öffentlichen oder gemeinsam genutzten WLAN, starten Sie Wireshark und überwachen Sie die Aktivitäten mit Port 80. Dann werden Sie schnell erkennen, warum das Abhören ein Problem darstellt und wie TLS dies effektiv verhindert. Andernfalls möchten Sie möglicherweise eine neue Frage stellen, da die Erörterung der Sicherheitsvorteile und -beschränkungen von TLS hier etwas außerhalb des Anwendungsbereichs liegt.
    IMSoP
    2015-05-04 18:48:29 UTC
    view on stackexchange narkive permalink

    Die Verwendung einer automatisierten Prüfung gilt nicht nur für diese Zertifizierungsstelle, ist jedoch für Einstiegszertifikate üblich. Wie in anderen Antworten angegeben, werden drei Zertifikatebenen verwendet:

    • Die Doman-Validierung zeigt nur, dass Sie zum Zeitpunkt der Ausstellung des Zertifikats die Kontrolle über die Domain hatten. (Und dass das Zertifikat seitdem nicht explizit widerrufen wurde.)
    • Die Organisationsvalidierung beinhaltet eine zusätzliche Überprüfung, ob der im Zertifikat aufgeführte Firmenname gültig ist.
    • Die erweiterte Validierung enthält a viel stärkere Prüfung des Unternehmens, das das Zertifikat beantragt.

    Für ein grundlegendes DV-Zertifikat (und als ersten Schritt in OV- und EV-Anwendungen) verwenden die meisten Zertifizierungsstellen eine Form automatisierter "Domain" Kontrollvalidierung ". Zum Beispiel bietet Comodo drei Optionen:

    1. Eine E-Mail muss von einer kurzen Liste generischer Adressen in der Domain empfangen werden, z. B. "admin @". "unter der Annahme, dass nur autorisierte Mitarbeiter Zugriff auf diese Postfächer haben würden.
    2. In der DNS-Zone für die Domain muss ein bestimmter CNAME-Eintrag hinzugefügt werden, um nachzuweisen, dass der Antragsteller über DNS-Kontrolle verfügt.
    3. Im Stammverzeichnis des HTTP der Domain muss eine URL mit einem bestimmten Inhalt hinzugefügt werden, um zu beweisen, dass der Antragsteller die Kontrolle über den Webserver hat, auf den die Domain verweist.
    4. ol>

      Die Das ACME-Protokoll, das im Rahmen der Lets Encrypt-Bemühungen entwickelt wird, dient der Automatisierung der Client -Seite dieser Prüfung. In ihrer Technologieübersicht werden sowohl die DNS-basierten als auch die HTTP-basierten Prüfungen als Beispiele genannt, die auf diese Weise automatisiert werden könnten.

      Die Idee ist, dass die von Ihnen installierte Software anhand der Konfiguration, auf die sie Zugriff hat, automatisch bestimmen kann, wie diese Herausforderungen bewältigt werden sollen. Wenn es das Dokumentstammverzeichnis der zu validierenden Domäne finden und in dieses schreiben kann, ist die HTTP-basierte Herausforderung sehr einfach zu automatisieren. Die traditionellere E-Mail-basierte Validierungsmethode wäre aufgrund der Komplexität der E-Mail-Zustellung schwieriger zu automatisieren, unterscheidet sich jedoch nicht in der Menge der von ihr bereitgestellten Beweise.

    J.C.
    2015-05-05 11:05:55 UTC
    view on stackexchange narkive permalink

    Die primäre Verteidigung gegen MITM-Angriffe während der Ausgabe besteht darin, die Validierungsprüfung unter Beobachtung des Servers oder seines DNS an vielen geografisch verteilten Standorten durchzuführen. So viele Zertifizierungsstellen arbeiten heute für automatisierte Webprüfungen, um Fälschungen und Betrug aufzudecken.

    Nach dem, was ich im IRC-Raum gehört habe, wird Let's Encrypt für alle Validierungsprüfungen dasselbe tun. P. >

    Es hilft nicht, wenn sich MITM in der Nähe Ihres Servers befindet (wenn nur eine einzige Route verfügbar ist).
    mcfedr
    2020-09-03 15:38:01 UTC
    view on stackexchange narkive permalink

    Denken Sie daran, dass Sie nicht die Benutzer der Site MITM, sondern Validierungsserver von Encrypts verwenden müssen, um dieses Zertifikat zu erhalten. Dies wird viel schwieriger.

    Lets Encrypt hat kürzlich darüber gesprochen, wie sie Verwenden Sie Multi-Perspective Validation, um sich vor einem solchen Angriff zu schützen. Die Idee ist, dass Ihr Besitz der Domain von verschiedenen Stellen im Internet aus überprüft wird, sodass Sie mehrere Rechenzentren MITM benötigen würden auf der ganzen Welt.

    In diesem Fall ist Lets Encrypt meiner Meinung nach sicherer als andere Zertifikatanbieter, die sich nicht so sehr bemühen, sich selbst zu schützen. Dies ist nichts Besonderes für Lets Encrypt. Wenn Sie den Zertifikatsanbieter MITM verwenden können, können Sie einen von ihnen verwenden. Dies ist möglicherweise teurer für Sie.

    Nun, einige Zertifikatanbieter versuchen, Ihre reale Identität zu überprüfen.Nicht so sehr, seit LE existiert.
    Für EV-Zertifikate sollten sie dies tun, aber für DVs, die Lets Encrypt Ihnen zur Verfügung stellt, sind andere Anbieter ähnlich und tendieren ebenfalls dazu, automatisch zu sein, jedoch weniger strukturiert als das ACME-Protokoll.


    Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 3.0-Lizenz, unter der er vertrieben wird.
    Loading...