Abo
  1. Foren
  2. Kommentare
  3. Security
  4. Alle Kommentare zum Artikel
  5. › E-Mail-Verschlüsselung: PGP und S…

Der Artikel ist Murks

  1. Thema

Neues Thema Ansicht wechseln


  1. Der Artikel ist Murks

    Autor: Kelran 14.05.18 - 11:18

    Ich kritisiere die Arbeit anderer normalerweise nicht mit derart harschen Worten, aber dieser Artikel ist wirklich ganz großer Mist. Bei allem Verständnis für eine manchmal überhastete Berichterstattung und dem Interesse an Lesern, ist es völlig daneben undifferenziert Panik zu verbreiten und die Leser in die Irre zu führen.

    Schauen wir uns das Gesagte doch einmal an und welche Folgerung auf die Sicherheitslücke man daraus ziehen müsste: Es müsste eine Schwachstelle sein, die unabhängig vom Betriebssystem und E-Mail-Client sowohl GnuPG/PGP als auch S/SMIME betrifft, gleichzeitig darf die Schwachstelle aber nicht in der Verschlüsselung selbst liegen, denn sonst wäre nicht nur die E-Mails betroffen.

    Vielleicht liegt es an meiner mangelnden Phantasie, aber ich kann mir keinen darauf passenden Angriffsvektor vorstellen. Es muss weitere wichtige Rahmenbedingungen geben.

    Mindestens eine dieser Bedingungen ist wohl die automatische Entschlüsselung. Das wird bei dem Angriffsvektor auch der entscheidende Punkt sein. Der Artikel erwähnt es, geht aber nicht näher darauf ein. Was verstehen die sehr um Aufmerksamkeit bemühten Forscher unter "automatischer Entschlüsselung"?

    Ist die automatische Entschlüsselung die Funktion, welche das Kennwort abfragt und die Entschlüsselung und Anzeige der E-Mail vornimmt? Dann wäre das Abschalten zwar nicht unbedingt notwendig, wohl aber der Verzicht auf die Nutzung der Erweiterung des E-Mail-Clients, die sich um die Ver-/Entschlüsselung kümmert. Andere Fälle sind jedoch ebenfalls denkbar, beispielsweise der Verzicht auf ein Kennwort (das ist idiotisch) oder das längere (Zwischen-)Speichern des Kennworts in irgendeiner Form. Dann würde es ausreichen, dieses Verhalten anzupassen und man könnte die Erweiterung weiter nutzen.

    Eine weitere wichtige Rahmenbedingung könnte der Parser für die E-Mails sein. Ich tippe darauf (reines Bauchgefühl), dass er auch betroffen ist.

    Ach ja: Es ist bei GnuPG/PGP vollkommen normal, dass man alte E-Mails entschlüsseln kann, falls man im Besitz des privaten Schlüssels nebst Kennwort ist. Ober soll damit gemeint sein, dass es ohne Schlüssel und/oder ohne Kennwort bei einem Kennwort-geschützen Schlüssel geht?



    4 mal bearbeitet, zuletzt am 14.05.18 11:26 durch Kelran.

  2. Re: Der Artikel ist Murks

    Autor: joeboefish 14.05.18 - 11:50

    Ja, es fällt schon auf, dass bei Heise und Chip so rein gar nichts steht.

    Sollte die Sicherheitslücke eine vorherige Kompromittierung des Rechners verlangen? Na dann hat man ganz andere Probleme, als dass die Malware auch diese Tools angreifen kann.

    Und was ist das überhaupt für ein Verhalten, eine Warnung rauszuhauen, und dann nicht zu sagen, was Sache ist.

    Mal schauen, ob für mich die EFF morgen gestorben ist.

  3. Re: Der Artikel ist Murks

    Autor: Kelran 14.05.18 - 11:51

    Jetzt sind wir eine Stunde weiter und ich habe u. a. eine sehr aufschlussreiche Bemerkung vom CRO von F-Secure gefunden: https://twitter.com/gnupg/status/995931083584757760

    @Golem: Wie gesagt, der Artikel ist Murks.

  4. Der Artikel ist kein Murks

    Autor: Mingfu 14.05.18 - 12:17

    In einem anderen Thread ist schon ein relativ guter Hinweis auf die Ursache des Problems verlinkt: Sowohl OpenPGP als auch S/MIME sehen keinen obligatorischen Schutz gegen die Manipulation von verschlüsselten Nachrichten vor. Das eröffnet (zusammen mit der Anzeige von in HTML-Nachrichten eingebetteten Links als Rückkanal) eine Möglichkeit für Orakel-Angriffe, mittels derer ein Angreifer etwas über den Klartext einer durch ihn (auch in der Vergangenheit) abgefangenen verschlüsselten Nachricht erlernen kann.

    OpenPGP sieht zwar einen (von der kryptographischen Sicherheit allerdings durchaus fragwürdigen) Hash der Nachricht als Modifikationserkennung vor, aber eben nicht obligatorisch, weil es erst nachträglich in den Standard aufgenommen wurde und deshalb wegen der Rückwärtskompatibilität nicht verpflichtender Bestandteil der Nachricht ist. Es gibt zwar beim Entschlüsseln einen Hinweis, wenn dieser Hash fehlt, aber was man mit diesem Hinweis anfängt, dass ist dann eben abhängig von E-Mail-Programm bzw. Anwender.

    Damit ist die Warnung, das automatische Entschlüsseln von Nachrichten grundsätzlich zu unterlassen, durchaus voll und ganz berechtigt.

  5. Re: Der Artikel IST Murks

    Autor: Kelran 14.05.18 - 12:27

    Mingfu schrieb:
    --------------------------------------------------------------------------------
    >
    > Damit ist die Warnung, das automatische Entschlüsseln von Nachrichten
    > grundsätzlich zu unterlassen, durchaus voll und ganz berechtigt.

    Das hat auch niemand bestritten. Das ist genauso sinnvoll, wie die Anzeige von (interpretiertem) HTML in E-Mails zu deaktivieren. Das war aber nicht der Kern der maßlos überzogene Meldung - weder der von Golem noch der von der EFF.



    1 mal bearbeitet, zuletzt am 14.05.18 12:39 durch Kelran.

  6. Re: Der Artikel ist kein Murks

    Autor: My1 14.05.18 - 12:28

    wie wäre es wenn bspw ne mail beim verschlüsseln vom absender signiert wird und es wird nir dann was gemacht wenn die sig stimmt?

    Asperger inside(tm)

  7. Re: Der Artikel ist DOCH Murks

    Autor: Jad 14.05.18 - 12:30

    Abgesehen davon, dass E-Mails mit HTML für jemanden, der Verschlüsselung braucht, sowieso ein No-Go sind, ist das alles mal wieder Panikmache von Forschern, die Aufmerksamkeit brauchen.

    https://lists.gnupg.org/pipermail/gnupg-users/2018-May/060315.html

  8. Re: Der Artikel ist Murks

    Autor: Kelran 14.05.18 - 12:37

    2. Aktualisierung: Im Blog von Mike Kuketz stehen noch einige Informationen zur Schwachstelle drin: https://www.kuketz-blog.de/dont-panic-sicherheitsluecke-in-pgp/

    Einem Zitat dort kann man auch entnehmen, dass Sebastian Schinzel und Damian Poddebniak es nicht einmal für notwendig gehalten haben, das GnuPG Team im Vorfeld zu kontaktieren. So sagt es Werner Koch, ja DER Werner Koch (Entwickler von GnuPG).

    Ganz tolle Leistung von den beiden Forscher. Eine Schwachstelle medial aufblasen und dann auch noch fragwürdig kommunizieren.

  9. Der Artikel ist kein Murks

    Autor: Mingfu 14.05.18 - 12:39

    Ich habe schon geschrieben, was ich von diesen Ansichten der GnuPG-Verantwortlichen halte.

    In meinen Augen zeigt das einen völlig unprofessionellen Umgang mit Sicherheitsproblemen. Und das erklärt dann eben auch, weshalb das OpenPGP-Protokoll so bescheiden ist, wie es ist, wenn solche Leute dort verantwortlich zeichnen.

  10. Re: Der Artikel ist kein Murks

    Autor: Kelran 14.05.18 - 12:55

    Mingfu schrieb:
    --------------------------------------------------------------------------------
    > Ich habe schon geschrieben, was ich von diesen Ansichten der
    > GnuPG-Verantwortlichen halte.
    >

    Habe ich gelesen. Zustimmen kann ich dem nur begrenzt, denn es gibt ein Grund, warum dort "SHOULD" steht und es gibt eine klare Vorschrift, wie das SHOULD zu interpretieren ist, nämlich "... mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course." (siehe https://www.ietf.org/rfc/rfc2119.txt).

    Der Grund ist wie von Dir auch schon erwähnt die Rückwärtskompatiblität. Ein "MUST" würde diese brechen. Das wäre 2007 meiner Meinung nach nicht angemessen gewesen. Es ist ja auch kein neuer Standard.

    Aus meiner Sicht wäre es sinnvoll, den Standard zu aktualisieren, wie dies bereits mit RFC 5581 (https://tools.ietf.org/html/rfc5581) minimal geschehen ist. Und sicherlich hätte man dies schon lange tun können.

    Falls Du in dem Bereich über fundiertes Fachwissen verfügst, wäre es nett, wenn Du das Thema in Angriff nehmen würdest.

  11. Re: Der Artikel ist Murks

    Autor: Kelran 14.05.18 - 13:08

    3. Aktualisierung: Eine Einschätzung von Werner Koch zu der Schwachstelle (GnuPG Entwickler): https://lists.gnupg.org/pipermail/gnupg-users/2018-May/060315.html

  12. Re: Der Artikel ist Murks

    Autor: ClemensPetzold 15.05.18 - 01:59

    Wie mein Vorredner bereits erwähnt hat ist der Knackpunkt die Parameter unter dem das Szenario greifen kann: Wenn man sich selbst ein SMIME Zertifikat craftet leuchtet mir die Problematik vollkommen ein und zudem auch noch keine gesicherte Verbindung zum Server hat. Aber SMIME ist eben nicht nur zum verschlüsseln der Mail, sondern auch zur Identifikation. Man bräuchte also nur die Entschlüsselung von Mails ausschließen, die nicht eindeutig verifizierbar sind. Eine maninthemiddle Attacke ist schwierig bei Leuten die ihre Mails verschlüsseln aber dann nicht auf eine gesichtete Übertragung achten.

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. Beckhoff Automation GmbH & Co. KG, Verl
  2. Bosch Gruppe, Grasbrunn
  3. Jade Hochschule Wilhelmshaven/Oldenburg/Elsfleth, Oldenburg
  4. Hanseatisches Personalkontor, Großraum Frankfurt am Main

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. 34,99€ (erscheint am 15.02.)
  2. (-63%) 34,99€
  3. (-78%) 8,99€
  4. 25,49€


Haben wir etwas übersehen?

E-Mail an news@golem.de


C64-WLAN-Modem ausprobiert: Mit dem C64 ins Netz
C64-WLAN-Modem ausprobiert
Mit dem C64 ins Netz

WLAN am C64 per Steckmodul - klingt simpel und nach einer interessanten Spielerei. Wir haben unseren 8-Bit-Commodore ins Netz gebracht und dabei geschafft, woran wir in den frühen 90ern gescheitert sind: ein Bulletin-Board zu besuchen.
Ein Erfahrungsbericht von Martin Wolf

  1. Klassiker Internet Archive bietet Tausende spielbare C64-Games

Linux-Kernel CoC: Endlich normale Leute
Linux-Kernel CoC
Endlich normale Leute

Als Linus Torvalds sich für seine Unflätigkeit entschuldigte und auch die Linux-Community Verhaltensregeln erhielt, fürchteten viele, die Hölle werde nun zufrieren und die Community schwer beschädigt. Stattdessen ist es eigentlich ganz nett geworden dort.
Eine Analyse von Sebastian Grüner

  1. Kernel ZFS für Linux bekommt GPL-Probleme
  2. Betriebssysteme Linux 5.0rc1 kommt mit Freesync und Adiantum
  3. Retpoline Linux-Kernel soll besseren Spectre-Schutz bekommen

Slighter im Hands on: Wenn das Feuerzeug smarter als der Raucher ist
Slighter im Hands on
Wenn das Feuerzeug smarter als der Raucher ist

CES 2019 Mit Slighter könnte ausgerechnet ein Feuerzeug Rauchern beim Aufhören helfen: Ausgehend von den Rauchgewohnheiten erstellt es einen Plan - und gibt nur zu ganz bestimmten Zeiten eine Flamme.
Ein Hands on von Tobias Költzsch

  1. H2Bike Alpha Wasserstoff-Fahrrad fährt 100 Kilometer weit
  2. Bosch Touch-Projektoren angesehen Virtuelle Displays für Küche und Schrank
  3. Mobilität Das Auto der Zukunft ist modular und wandelbar

  1. DEV Systemtechnik: Distributed CCAP Nodes sollen 10 GBit/s im Kabelnetz bringen
    DEV Systemtechnik
    Distributed CCAP Nodes sollen 10 GBit/s im Kabelnetz bringen

    Mit neuen Distributed-CCAP-Geräten, die bis zu 1.000 angeschlossene Kabelmodems pro Gerät unterstützen, soll ein maximaler Datendurchsatz von mehr als 10 GBit/s pro Knoten im Kabelnetz erreicht werden. Die Docsis-3.1.-Technik kommt aus Deutschland.

  2. Ausrüster: Nokia Deutschland baut massiv Arbeitsplätze ab
    Ausrüster
    Nokia Deutschland baut massiv Arbeitsplätze ab

    Bei Nokia Deutschland werden 15 Prozent der Arbeitsplätze in allen Bereichen gestrichen. Offenbar laufen die Geschäfte trotz 5G-Einführung nicht zufriedenstellend, weil die USA den Handelskrieg mit China weiter anheizen.

  3. Amazon: Fire TV Stick erhält verbesserte Fernbedienung ohne Aufpreis
    Amazon
    Fire TV Stick erhält verbesserte Fernbedienung ohne Aufpreis

    Amazon verkauft den normalen Fire TV Stick mit einer verbesserten Fernbedienung. Damit lässt sich auch die Lautstärke des Fernsehers oder einer Soundbar steuern. Kurzzeitig gibt es die Fire-TV-Fernbedienung einzeln zum halben Preis.


  1. 20:07

  2. 18:46

  3. 18:00

  4. 17:40

  5. 17:25

  6. 17:13

  7. 17:04

  8. 16:22