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. BWI GmbH, Regen
  2. Bosch Gruppe, Reutlingen
  3. TeamBank, Nürnberg
  4. Bosch Gruppe, Stuttgart

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Blu-ray-Angebote
  1. (u. a. Outlander, House of Cards)
  2. (2 Monate Sky Ticket für nur 4,99€)
  3. (Prime Video)


Haben wir etwas übersehen?

E-Mail an news@golem.de


Automatisiertes Fahren: Der schwierige Weg in den selbstfahrenden Stau
Automatisiertes Fahren
Der schwierige Weg in den selbstfahrenden Stau

Der Staupilot im neuen Audi A8 soll der erste Schritt auf dem Weg zum hochautomatisierten Fahren sein. Doch die Verhandlungen darüber, was solche Autos können müssen, sind sehr kompliziert. Und die Tests stellen Audi vor große Herausforderungen.
Ein Bericht von Friedhelm Greis

  1. Autonomes Fahren Ford will lieber langsam sein
  2. Navya Mainz testet autonomen Bus am Rheinufer
  3. Drive-by-wire Schaeffler kauft Lenktechnik für autonomes Fahren

Razer Huntsman im Test: Rattern mit Infrarot
Razer Huntsman im Test
Rattern mit Infrarot

Razers neue Gaming-Tastatur heißt Huntsman, eine klare Andeutung, für welchen Einsatzzweck sie sich eignen soll. Die neuen optomechanischen Switches reagieren schnell und leichtgängig - der Geräuschpegel dürfte für viele Nutzer aber gewöhnungsbedürftig sein.
Ein Test von Tobias Költzsch

  1. Huntsman Razer präsentiert Tastatur mit opto-mechanischen Switches
  2. Razer Abyssus Essential Symmetrische Gaming-Maus für Einsteiger
  3. Razer Nommo Chroma im Test Blinkt viel, klingt weniger

Threadripper 2990WX und 2950X im Test: Viel hilft nicht immer viel
Threadripper 2990WX und 2950X im Test
Viel hilft nicht immer viel

Für Workstations: AMDs Threadripper 2990WX mit 32 Kernen schlägt Intels ähnlich teure 18-Core-CPU klar und der günstigere Threadripper 2950X hält noch mit. Für das Ryzen-Topmodell muss aber die Software angepasst sein und sie darf nicht zu viel Datentransferrate benötigen.
Ein Test von Marc Sauter

  1. 32-Kern-CPU Threadripper 2990WX läuft mit Radeons besser
  2. Threadripper 2990WX AMDs 32-Kerner kostet weniger als Intels 18-Kerner
  3. Zhongshan Subor Z+ AMD baut SoC mit PS4-Pro-Leistung für chinesische Konsole

  1. Let's Play: Valve streamt über Steam.tv
    Let's Play
    Valve streamt über Steam.tv

    Es könnte weitere Konkurrenz für Youtube und Twitch geben: Valve arbeitet an einem eigenen Angebot, das wahrscheinlich mit dem E-Sport-Turnier The International startet. Wie es dann weitergeht - unklar.

  2. Promotion: Netflix testet Werbung zwischen Serienepisoden
    Promotion
    Netflix testet Werbung zwischen Serienepisoden

    Netflix legt viel Wert darauf, dass Nutzer sich Serien fast nahtlos ansehen können. Nun wird eine Funktion getestet, die zwischen einzelnen Folgen doch etwas Werbung einblendet - für Netflix-eigene Inhalte.

  3. Breitbandausbau: Bahn will eigenes Glasfasernetz neben Gleisen ausbauen
    Breitbandausbau
    Bahn will eigenes Glasfasernetz neben Gleisen ausbauen

    Die Bahn hat bereits ein umfangreiches Glasfasernetz und will es entlang der Gleise nun massiv ausbauen. Dafür wird ein Partner aus der Netzbetreiberbranche gesucht.


  1. 11:33

  2. 11:04

  3. 18:00

  4. 17:30

  5. 17:15

  6. 16:50

  7. 16:25

  8. 16:00