Wie der Iran mit Hilfe einer niederländischen Firma GMAIL abhörte

Die in Holland ansässige Firma Diginotar hat der iranischen Regierung offenbar zu einem SSL-Zertifikat verholfen, mit dem verschlüsselte SSL-Verbindungen zu Gmail abgehört werden konnten. (zuletzt in dieser Reihe: Wie Bahrain bei der Überwachung auf deutsche Wertarbeit setzt und Was ist da in Tunesien los?)

Die Herausforderung bei verschlüsselten Verbindungen ist, dass sichergestellt werden muss, dass man nicht nur verschlüsselt, sondern auch so verschlüsselt, dass niemand anderes mithören kann. Mithören könnte ja zum Beispiel ein man-in-the-middle-Angreifer, indem er sich zwischen die beiden kommunizierenden Rechner (Client & Server) klinkt, eine verschlüsselte Verbindung zum Nutzer mit einem eigenen Zertifikat aufbaut, diese abhört, und dann erst mit dem richtigen Zertifikat verschlüsselt an den richtigen Server weiterleitet. Um das zu verhindern, sollen die zur Verschlüsselung genutzten Zertifikate immer von einer vertrauenswürdigen Instanz signiert sein.

Einem üblichen Browser wie Firefox werden deshalb eine ganze Reihe an root-CAs mitgeliefert, denen standardmäßig vertraut wird. Wenn ein Zertifikat von einer Instanz signiert ist, deren CA nicht um Browser (per default oder nachträglich) installiert ist, kommt die altbekannte Warnmeldung “Dieser Verbindung wird nicht vertraut” – Der Nutzer muss das Zertifikat dann selbst prüfen und ihm quasi einmal das Vertrauen aussprechen. Die gleiche (oder bei manchen Browsern sehr ähnliche) Warnung bekommt ihr, wenn ein mittelloser Hacker euch zum Ziel einer man-in-the-middle-Attacke auserwählt hat, aber nicht im Besitz eines signierten Zertifikats ist.

Die Firmen im Besitz der standardmäßig mitgelieferten CAs verdienen also gutes Geld, weil sie der einzige Weg sind, einem DAU die vermeintlich sichere Nutzung der Seite ohne unverständliche Fehlermeldungen zu ermöglichen. Noch mehr Geld aber können sie natürlich damit verdienen, bösen Menschen Zertifikate für Domains auszustellen, die sie gar nicht besitzen.

So beispielsweise der iranischen Regierung, wenn diese gerne GMAIL-Verbindungen ihrer Bürger abhören möchte. Mit einem eigenen signierten Zertifikat (zu dem sie dann auch den private key hat), könnte sie automatisiert das Gmail-Zertifikat on the fly gegen ihr (signiertes) gefälschtes tauschen, ohne dass die meisten Browser sich beklagen. Das Zertifikat ist ja von einer vertrauenswürdigen Instanz signiert. Und genau das ist jetzt über 5 Wochen passiert.

[Update] Diginotar erklärt, sie wären gehackt worden – auch nicht besser! Dass sie das Zertifikat gegen Bezahlung erstellt haben ist immer eine Möglichkeit, aber natürlich auch eine möglicherweise ungeheuerliche Unterstellung. Das Problem ist, dass jede einzelne dieser vielen CAs, von denen man selbst keine bis wenige kennt, geschweige denn ihre Vertrauenswürdigkeit oder die Sicherheit ihres Systems beurteilen zu kann. [/Update]

Dass dieses Modell irgendwann mal schief gehen muss, ist offensichtlich, vor allem wenn man sich die Anzahl der default-CAs in Firefox anschaut, oder einfach mal einen Blick auf die Firmen wirft, die da überall ihre Finger im Spiel haben. Deshalb gibt es Ansätze wie CAcert, die das Signieren kostenlos, als Community und transparent gestalten. Viel mehr Vertrauen hat man dadurch aber natürlich auch nicht unbedingt verdient.

Deshalb ist es interessanter zu schauen, wie Zertifikat-Manipulationen herauskommen: Indem Nutzer sich die Zertifikate anschauen und vergleichen. Und zwar mit Personen, denen sie vertrauen. Die einzig sicherere Konsequenz scheint also zu sein, sich von den großen zentralen SSL-CAs, die viel Macht in sich versammeln (ein paar Hundert Firmen wachen quasi über ca. 80% des “sicheren” Web-Traffics) zu trennen, und wie ähnlich wie beim GPG web of trust vorzugehen: Man vertraut Menschen. Das würde aber eine Menge an Fingerprint-Vergleichen auf sicheren Wegen mit Personen denen man vertraut, und eine Menge Warnmeldungen beinhalten. Wir können also davon ausgehen, dass sich das nicht unbedingt durchsetzen wird, denn Bequemlichkeit ist den meisten Menschen leider weitaus wichtiger als Sicherheit.

Wer es aber mal ausprobieren möchte, löscht einfach mal alle CA aus seinem Browser und nimmt nur jene wieder auf, denen er vertraut. Auf jeden Fall aber sollte man wohl Diginotar rauswerfen. Wie das geht, ist hier erklärt.

Wir lernen: In Zeiten, in denen sich HTTPS noch immer nicht ganz durchgesetzt hat, können wir es uns eigentlich schon wieder von der Backe putzen. Genau, wie es uns schon erklärt wird, seit es HTTPS gibt.

Dieser Eintrag wurde veröffentlicht in Datenschutz, Informationstechnologie und getagged , , . Bookmarken: Permanent-Link. Kommentieren oder ein Trackback hinterlassen: Trackback-URL. Dieser Beitrag steht unter der Lizenz CC BY-NC-SA: Linus Neumann, Netzpolitik.org.

24 Kommentare

  1. Stephan Urbach
    Erstellt am 30. August 2011 um 14:32 | Permanent-Link

    Ich sage schon die ganze Zeit, dass SSL broken beyond repair ist. Also, nicht die Technologie, sondern die Trustketten und alles, was mit den Zertifikaten zu tun hat.

    • Peter A.
      Erstellt am 31. August 2011 um 19:42 | Permanent-Link

      SSL ist nicht broken, es ist unverstanden (wie der Artikel, die Presse und die Kommentare zeigen). Die derzeitige Situation ist, die Browser sind durch Dritte vertrauensvoll vorkonfiguriert bzw. deren Zertifikat-Storages sind von vornherin auf vertrauensvoll eingestellt.

      Jede Voreinstellung in der Root-CA-Zertifikate per default als Vertrauenswürdig eingestuft weden ist nachteilig, bevormundend oder defekt weil damit Vertrauen an viele Stellen delegiert wird, die nicht zwangsläufig vertrauensvoll sind oder kompromittiert werden können, in diesem Fall DigiNotar bzw. Vasco.

      Es ist völlig unrelevant, wer nun dieses Zertifikat erstellt hat, er war auf jeden Fall nicht besonders intelligent. Wenn er in der Lage ist MITM durchzuführen oder Endpunkt-Addressen zu manipulieren, ist der Aufwand selbst eine CA zu implementieren und entsprechende Zertifikate zu erstellen marginal, die Wahrscheinlichkeit entdeckt zu werden ist wesentlich geringer wenn man keine dritte Instanz hinzuzieht.

      Derzeit delegiert man sein Vertrauen durch seinen Browser z.B. an die Mozilla Foundation, Google, MicroSoft oder wem auch immer (Opera, Apple usw. usf.).

      Dein Browserhersteller delegiert anschliessend weiter an die jeweiligen präferierten CAs, nur deshalb sind solche Angriffe möglich, siehe auch: https://bugzilla.mozilla.org/show_bug.cgi?id=647959 – ich halte Honest Achmed für ähnlich vertrauensvoll wie Verisign oder Thawte, niemand kann objektiv für jemand anderen beurteilen welche Zertifikatsstelle vertrauenswürdig ist oder nicht – das kann man nur selbst.

      Da hilft auch CAcert nicht. Keine Organisation kann bzw. sollte das für Dich tun.

      Solange man nicht selbst Zertifikate prüft und anschließend selbst in den Browser importiert, ist man in Sachen Krypto und bei MITM immer angeschmiert – soll heissen man kann auf SSL verzichten, wenn man nicht selbst prüft – das wäre dann der Status Quo.

      Wenn man schon dabei ist selbst zu prüfen, oder damit anfängt, kann man auch gleich den Mittelsmann, die Zertifizierungsstelle (CA), eliminieren und selbstzertifizierte Zertifikate verwenden.

      D.h. das Vertrauensverhältnis besteht dann zwischen zwei Parteien z.B. Netzpolitik, der Netzpolitik CA und dem Netzpolitik-Leser (Dir).

      Anschliessend kann man sich auch selbst Zertifikate ausstellen und sicher mit anderen Menschen kommunizieren.

      Natürlich kann man das auch alles wie bisher an Zertifizierungsstellen oder Browserhersteller delegieren und behaupten es würde nicht funktionieren oder nur solange funktionieren bis eine CA kompromittiert wird.

      Es ist aber wesentlich sinnvoller sich selbst mit Krypto auseinander zusetzen und es für sich selbst besser zu machen, anstatt zu inisistieren SSL wäre defekt oder einer CA zu attestieren, sie wäre (nicht) vertrauensvoll – es löst das Problem nicht.

      Linus man kann nicht “onthefly” ein Zertifikat austauschen, sondern man kann die SSL-bedingte sichere Sitzungs-Schlüsselübertragung zwischen Webserver und Browser kompromittieren, ein SSL-Relay erstellen und damit die sichere Ende-zu-Ende Verschlüsselung aufheben.

      Lasst Euch bitte nochmal SSL/TLS erklären, bevor Ihr einem unverstandenem Verfahren attestiert es wäre defekt, unbrauchbar oder nicht mehr zeitgemäss.

  2. Erstellt am 30. August 2011 um 14:39 | Permanent-Link

    Gerade die Anleitung zum Zertifikatsrausschmiss mit Iceweasel 5 probiert, unter Debian wheezy/sid. Interessant: Die Authority wird mit dem „Delete / Distrust“-Button aus der Liste entfernt; öffne ich den Einstellungsdialog erneut, ist sie zwar wieder da, beim Klick auf „Edit Trust“ zeigt sich aber: DigiNotar wird nicht mehr vertraut.

    Bei Chromium 13 sind die relevanten Einstellungen übrigens unter „Edit → Preferences → Under the Hood → Manage Certificates → Authorities“ zugänglich. Dort DigiNotar anwählen und „Edit …“ klicken, der „Delete“-Button ist ausgegraut.

  3. Erstellt am 30. August 2011 um 14:49 | Permanent-Link

    Zwei Plugins die einem das Leben deutlich einfacher machen:
    Perspectives – http://www.networknotary.org/firefox.html
    Certificate Patrol – http://patrol.psyced.org/

  4. flo
    Erstellt am 30. August 2011 um 14:51 | Permanent-Link

    Bei meinem Chrome ist das CA von Diginotar gar nicht dabei?!

    • Erstellt am 30. August 2011 um 14:53 | Permanent-Link

      Das ist dann wohl der Segen des Google-Updater-Fluchs. Diginotar fliegt jetzt natürlich bei allen raus. Ich vermute, dass du ein Update bekommen hast.

      • Erstellt am 30. August 2011 um 15:10 | Permanent-Link

        Bei Chromium 13.0.782.215 ist das Zertifikat noch drin.

      • Peter A.
        Erstellt am 31. August 2011 um 20:43 | Permanent-Link

        Chrome 14.0.835.122 beta hat auch noch ein DigiNotar Zertfikat vom 16.5.2007

  5. Erstellt am 30. August 2011 um 15:21 | Permanent-Link

    Na dann hoffen wir mal das Zertifikate von Diginotar in Zukunft nicht mehr als “gültig” dastehen, sondern erst bestätigt werden müssen, wie bei unbekannten Quellen.

  6. Klaus. D. Ebert
    Erstellt am 30. August 2011 um 17:19 | Permanent-Link

    Eine halbwegs sichere Mail ist eine PGP usw. verschlüsselte Mail, wenn man nicht gerade Staatsfeind # 1 ist. Ich hab HTTPS noch nie vertraut.

  7. anonymous
    Erstellt am 30. August 2011 um 17:42 | Permanent-Link

    Ich würde sagen, dass die Aktie von dem DigiNotars Mutterkonzern noch “Luft nach unten” hat

  8. Weirdo Wisp
    Erstellt am 30. August 2011 um 18:35 | Permanent-Link

    Ich finde es reichlich dreist von Linus, in diesem Text kaum versteckt einer bisher einigermaßen seriösen CA pauschal zu unterstellen, dass sie absichtlich falsche Zertifikate ausstellt, um viel Geld zu machen mit bösen Staaten. (Der Vertrauensverlust sowie die Probleme mit jetzt nicht mehr vertrauenswürdigen Zertifikaten zum Beispiel in den Niederlanden wiegt sehr schwer, das können ein paar 1000 € aus dem Iran nicht rechtfertigen.) Es ist doch eher von Dummheit (ungenaue Prüfung der Daten) oder einem Hack/Angriff von Innen auszugehen — und die Pressemitteilung nennt ja auch einen Hack.

    Linus’ Verschwörungstheorien passen auf Fefes Blog, nicht ab auf netzpolitik.org!

    • Erstellt am 31. August 2011 um 01:24 | Permanent-Link

      Lol +1elf!

      • Weirdo Wisp
        Erstellt am 1. September 2011 um 21:51 | Permanent-Link

        Stringente Argumentation, mit Quellen belegte Fakten — danke, Linus, Deine Diskussionskultur sollte ein Vorbild für uns alle sein.

      • Thommy
        Erstellt am 1. September 2011 um 22:21 | Permanent-Link

        Bitte nicht,
        “ihr alle” reicht mir jetzt schon.

  9. Erstellt am 31. August 2011 um 02:56 | Permanent-Link

    Das die Diginotar Leuts dumm und/oder unvorsichtig waren glaube ich sofort, dass sie aber gegen Geld absichtlich ein ein Cert an nicht berechtigte ausgegeben haben (wie Linus’ Eingangsartikel anzudeuten scheint) glaube ich keine Sekunde. So bescheuert ist keiner, sein gesamtes Geschäft zu riskieren. So Theorien gehören für mich in die selbe Ecke wie Chemtrail, wenn ich das mal so deutlich sagen darf.

  10. SeL
    Erstellt am 31. August 2011 um 09:19 | Permanent-Link

    Mozilla hat gerade die Firefox-Updates 6.0.1 und 3.6.21 veröffentlicht. Einzige Änderung ist die Entfernung des CA-Zertifikates. http://blog.mozilla.com/security/2011/08/29/fraudulent-google-com-certificate/

  11. Erstellt am 31. August 2011 um 10:55 | Permanent-Link

    Salve,

    kein Hinweis auf die Quelle, kein Hinweis auf igendeine Art von Beweis …

    Klingt ja glaubwürdig und technisch auch möglich, aber etwas mehr Butter wollen die Fische schon haben.

    Einfach: Die Firma hat es zugegeben, wenn auch als Fehler dargestellt.

    Vasco Data Security International Inc. (VDSI, $7.05, -$0.39, -5.24%) said a security incident at its DigiNotar unit resulted in the fraudulent issuance of public key certificate requests for a number of domains, including Google.com. The certificates are used to encrypt information and provide authentication online.
    http://online.wsj.com/article/BT-CO-20110830-709520.html

    Gruss

    Christoph

  12. Peter A.
    Erstellt am 31. August 2011 um 20:27 | Permanent-Link

    Der Vollständigkeit halber, wie Syrien Facebook abgehört hat (ich bin nicht gut bei Schlagzeilen): http://dankaminsky.com/2011/08/31/notnotar/

    • Weirdo Wisp
      Erstellt am 3. September 2011 um 17:23 | Permanent-Link

      Hättest Du den Artikel gelesen, wüsstest Du, dass das Zertifikat von Facebook stammt und Syrien eben nicht Facebook (jedenfalls mit diesem Zertifikat) abgehört hat.

  13. gregoa
    Erstellt am 31. August 2011 um 22:57 | Permanent-Link

    weils noch nicht erwaehnt wurde: http://web.monkeysphere.info/ ist ein projekt, das das openpgp web of trust auf verschluesselte kommunikation mit servern via https und ssh ausdehnt. also genau die alternative zu dem hierarchischen CA-kram.

5 Trackbacks

  1. [...] Ach übrigens: Die Verschlüsselung bei DE-Mail (also die Übertragung einer Klartext-Mail über HTTPS zu einem Server, der die Klartext-Mail lesen kann) ist genau so sicher gegen das Mitlesen oder gegen Manipulationen wie Google Mail über HTTPS – also gar nicht, wenn signierte Zertifikate auf irgend einem Weg in der Hand eines Abhörers auf der …. [...]

  2. [...] http://netzpolitik.org/2011/wie-der-iran-mit-hilfe-einer-niederlandischen-firma-gmail-abhorte/ « Rät­sel um Schwar­zen Tod gelösttei­len: ähnli­che Artikel:Der Iran vor der Mullah-Herrschaft Iran: Halal-Internet und seine Aus­wir­kung auf soziale Bewegungen Iran hin­dert pro­mi­nente Foto­gra­fin an WM-Reise UN-Menschenrechtsberichterstatter ersucht Iran um Einreiseerlaubnis Macht und Ohn­macht im Iran Tags: Internet, Iran, Netzpolitik, Wirtschaft [...]

  3. [...] http://netzpolitik.org/2011/wie-der-iran-mit-hilfe-einer-niederlandischen-firma-gmail-abhorte/ Teilen:DruckenE-MailFacebookTwitterMehrDiggStumbleUponLinkedInRedditLike this:LikeSei der Erste, dem dieser post gefällt. [...]

  4. [...] netzpolitik.org: Wie der Iran mit Hilfe einer niederländischen Firma GMAIL abhörte (via +Markus [...]

  5. [...] eben nicht. Spätestens seit den Skandalen um Zertifikatsherausgeber wie Diginotar (Infos), dem Abhören von GMail-Traffic durch den Iran und der weitreichenden BEAST-Attacke ist klar: SSL und TLS sind kaputt. So kaputt, [...]

Ihr Kommentar

Ihre E-Mail wird niemals veröffentlicht oder verteilt. Benötigte Felder sind mit * markiert

*
*

Du kannst diese HTML Tags und Attribute verwenden: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Anzeige
Die von uns verfassten Inhalte stehen unter der Lizenz CC BY-NC-SA.
Netzpolitik.org nutzt Wordpress. Das Design ist ein Thematic-Kind von Linus Neumann.