Folgen (bei alten PGP-Keys) des zwingenden MDC Integritätsschutz seit Enigmal 2.0.5

  • Um Rückfragen vorzubeugen, bitten wir um folgende Angaben:

    • Thunderbird-Version: 52.8.0
    • Betriebssystem + Version:Windows 7
    • Kontenart (POP / IMAP):IMAP
    • Postfachanbieter (z.B. GMX):t-online
    • PGP-Software / PGP-Version:enigmail 2.0.5
    • Eingesetzte Antivirensoftware:
    • Firewall (Betriebssystem-intern/Externe Software):AVIRA


    Hallo,


    plötzlich kann ich in Thunderbird mit enigmail 2.0.5 keine verschlüsselten e-Mails mehr lesen.

    Nach der Passwortabfrage kommt sofort die Meldung:

    Fehler - Nachricht enthält keinen Integritätsschutz (MDC)


    Auch das Senden von verschlüsselten e-Mails mit der Abfrage, ob der Betreff auch verschlüsselt werden soll scheint nicht zu funktionieren, denn wenn ich in "Gesendet" meine abgesandte e-Mail anschauen will, kommt ebenfalls obige Meldung.


    Müssen wir uns jetzt von PGP verabschieden mit dieser Verschlimmbesserung?


    Gruß

    Ch. Hanisch

  • Hallo,


    ich habe Thunderbird 52.8.0 und Enigmail 2.0.5 für meine heutigen Tests verwendet.


    Ich kann mir per PGP/MIME eine Nachricht (HTML und externer Inhalt) mit verschlüsselter Betreffzeile senden. Sowohl die Kopie in "Gesendet" als auch die wieder empfangene Nachricht kann ich ganz normal anzeigen lassen.


    Nutzt Du PGP/MIME oder Inline-PGP? Tritt das Problem bei allen alten Mails, nur bei neuen Mails oder sowohl alt als auch neu auf?

  • Hallo,

    ich habe Thunderbird 52.8.0 und Enigmail 2.0.5 für meine heutigen Tests verwendet.


    Ich kann mir per PGP/MIME eine Nachricht (HTML und externer Inhalt) mit verschlüsselter Betreffzeile senden. Sowohl die Kopie in "Gesendet" als auch die wieder empfangene Nachricht kann ich ganz normal anzeigen lassen.

    Das verstehe ich nicht. Hast Du die Test wirklich unter Windows mit Thunderbird 52.8.0 und enigmail 2.0.5 gemacht?


    Ich habe das Problem folgendermaßen lösen können.

    Folgender Link https://superuser.com/question…cted-when-using-gpg-symme

    mit dieser Stelle:

    ...
    Configuration file (recommended): add the following line to your ~/.gnupg/gpg.conf configuration file.

    cipher-algo AES256

    I recommend this approach because it will be used for all future GPG operations on this user account.
    There's nothing to change for the user to decrypt the file - GnuPG will detect this automatically.

    hat nach Hinzufügen der Zeile:

    Code
    1. cipher-algo AES256


    in c:\Users\WINDOWS_USER\AppData\Roaming\gnupg\gpg.conf

    das Problem bei mir behoben.


    Frage: Wie stelle ich ein, daß ich den Betreff nicht verschlüsseln will?


    Gruß

    Ch. Hanisch

  • Das ist eine Folge von EFail bzw. dem verbesserten Schutz davor. In den Release-Notes, die im Thunderbird auch angezeigt wurden, ist zu Enigmail 2.0.4 vermerkt:

    Zitat

    2. a workaround that stops decrypting PGP messages using old algorithms like CAST5 that are not MDC-protected


    Das besagt aber auch, dass die E-Mails zuvor nicht mit AES sondern z.B. mit CAST5 verschlüsselt wurden. Der Algorithmus selbst gilt immer noch als sicher. Dessen Verwendung entspricht aber meines Wissens nicht den Standardeinstellungen von Enigmail sondern wurde wahrscheinlich durch den Benutzer festgelegt.

    Sinnvoll ist hier, Änderungen an Konfigurationsdateien stets gut und mit Datum zu kommentieren.


    Übersehen:


    Wie stelle ich ein, daß ich den Betreff nicht verschlüsseln will?

    Eingmail-Einstellungen, Tab Erweitert.

  • Hast Du die Test wirklich unter Windows mit Thunderbird 52.8.0 und enigmail 2.0.5 gemacht?

    Jawohl.


    Ich habe in all den Jahren jedenfalls nie den Algorithmus für PGP/Enigmail gewählt/verändert. Und sonst (bezüglich PGP/Enigmail) nie in Config-Files rund um PGP etwas per Editor eingetragen. Alles wurde soweit ich mich erinnern kann immer nur für meine verschiedensten Tests innerhalb von Thunderbird/Enigmail eingestellt. Anscheinend wird bei mir also ein "moderner" Algorithmus verwendet. Wirklich alte PGP-Mails besitze ich allerdings gar nicht mehr.

  • Hallo,

    Ich habe in all den Jahren jedenfalls nie den Algorithmus für PGP/Enigmail gewählt/verändert. Und sonst (bezüglich PGP/Enigmail) nie in Config-Files rund um PGP etwas per Editor eingetragen. Alles wurde soweit ich mich erinnern kann immer nur für meine verschiedensten Tests innerhalb von Thunderbird/Enigmail eingestellt. Anscheinend wird bei mir also ein "moderner" Algorithmus verwendet. Wirklich alte PGP-Mails besitze ich allerdings gar nicht mehr.

    Auch wir haben nie in Config-Files rund um PGP etwas per Editor eingetragen.

    Allerdings sind unsere PGP-Schlüsselpaare schon recht alt, z.B vom 10.12.2007.

    Das dürfte aber mit dem Problem :

    Fehler - Nachricht enthält keinen Integritätsschutz (MDC)

    was erstmalig unter enigmail 2.0.5 auftrat, nichts zu tun haben.


    Vielleicht ist bei Dir in der gpg.conf die Zeile:

    cipher-algo AES256

    schon eingetragen gewesen.


    Gruß

    Ch. Hanisch

  • Bei mir dürfte es sich um die Standard-Datei handeln, die momentan so ausgeliefert wird. Darin steht genau das:

    Code
    1. keyserver hkp://keys.gnupg.net
    2. cert-digest-algo SHA256
    3. no-emit-version
    4. no-comments
    5. personal-cipher-preferences AES AES256 AES192 CAST5
    6. personal-digest-preferences SHA256 SHA512 SHA384 SHA224
    7. ignore-time-conflict
    8. allow-freeform-uid
  • Hallo,

    Bei mir dürfte es sich um die Standard-Datei handeln, die momentan so ausgeliefert wird. Darin steht genau das:

    Code
    1. keyserver hkp://keys.gnupg.net
    2. cert-digest-algo SHA256
    3. no-emit-version
    4. no-comments
    5. personal-cipher-preferences AES AES256 AES192 CAST5
    6. personal-digest-preferences SHA256 SHA512 SHA384 SHA224
    7. ignore-time-conflict
    8. allow-freeform-uid


    und wo finde ich diese Standard-Datei in meinem Windows-System?


    Gruß

    Ch. Hanisch

  • Hallo,

    C:\Users\%USERNAME%\AppData\Roaming\gnupg\gpg.conf


    Bei mir zur Zeit GnuPG 2.2.3

    Bei mir Gpg4win (2.3.3).

    In der gpg.conf steht bei mir nur:



    Komisch - Warum dieser Unterschied?


    "Bei mir dürfte es sich um die Standard-Datei handeln, die momentan so ausgeliefert wird" - Von welchem Programm wird das ausgeliefert, wann und durch wen wird diese gpg.conf angelegt?


    Gruß

    Ch. Hanisch

    Einmal editiert, zuletzt von Hanisch ()

  • Einige Erläuterungen, mit meinem Wissenstand dazu, der aber auch in den Jahren angelesen ist und daher teilweise aus dem Gedächtnis kommt:

    Die Frage, welches symmetrische Verfahren für die Verschlüsselung Verwendung findet, entscheidet sich anhand der Präferenzen von Sender und Empfänger. Man kann sie zu jedem Schlüssel überprüfen

    Code
    1. gpg2 --edit-key keyid showpref


    Für einen alten, abgelaufenen Key von Werner Koch aus 1998 erhalte ich damit

    Code
    1. Verschlü.: AES256, AES192, AES, CAST5, 3DES
    2. Digest: SHA1, RIPEMD160
    3. Komprimierung: ZLIB, ZIP, nicht komprimiert
    4. Eigenschaften: MDC, Keyserver no-modify



    Das fast gleiche Ergebnis erhalte ich für den aus 2006 stammenden aber gültigen Schlüssel des BSI für die Buerger-CERT Signatur. Dort ist ganz am Ende noch IDEA aufgenommen.

    Neuere Schlüssel zeigen lediglich eine Änderung beim Digest.


    Code
    1. Verschlü.: AES256, AES192, AES, CAST5, 3DES, IDEA
    2. Digest: SHA256, SHA1, SHA384, SHA512, SHA224
    3. Komprimierung: ZLIB, BZIP2, ZIP, nicht komprimiert
    4. Eigenschaften: MDC, Keyserver no-modify


    Es spricht somit vieles dafür, dass die Reihenfolge in den Standardeinstellung in GnuPG bereits seit vielen Jahren AES256, AES192, AES, CAST5, 3DES lautet. Vielleicht war das PGP anders.


    Beim Senden einer verschlüsselten E-Mail werden die Präferenzen des Empfängers mit denen des Absenders verglichen, um den besten gemeinsamen Algorithmus zu finden. Sofern nichts verändert wurde, wäre das vermutlich schon seit mindestens 1998 AES256 und kein alter Algorithmus wie CAST5.


    Von welchem Programm wird das ausgeliefert, wann und durch wen wird diese gpg.conf angelegt?

    Die gpg.conf ist nicht zwingend erforderlich. Sie ist optional. Die wichtigsten Einstellung sind hart verdrahtet. Die gpg.conf wird nur benötigt, wenn man Standardeinstellungen verändert. Das kann über die Kommandozeile geschehen oder über graphische Oberflächen wie GPA oder Pinentry.

    Ferner kann man über "--options filename" auch eine ganz andere Datei als Konfig-Datei angeben. Schlussendlich erlaubt Windows auch, die Einstellungen nicht nur für einen Benutzer sondern z.B. auch für alle festzulegen.

    Ohne Einblick auf das konkrete Systems und die Historie ist es aus Ferne schwer zu beurteilen, welche Änderungen vorgenommen wurden und welche Konfiguration überhaupt greift.

  • Hallo,

    jetzt stelle ich fest, daß mit enigmail 2.0.5 und sowohl meiner gpg.conf als auch der von Thunder nur die allerletzten verschlüsselten e-Mails geöffnet werden können.

    Ältere e-Mail bzw. andere bringen den bekannten

    Fehler - Nachricht enthält keinen Integritätsschutz (MDC)


    Also da ist doch etwas mit enigmail 2.0.5 oberfaul.


    Gruß

    Ch. Hanisch

  • Hallo,

    Ich denke, dieses Thema könnte die Lösung sein:

    https://sourceforge.net/p/enig…/support/thread/03ebee57/


    Allerdings wird das eine Zeit lang vermutlich auch wieder zugunsten der Sicherheit zu Frust führen, so wie ich das sehe.

    Na, so geht das eigentlich aber nicht.

    Da werde ich wohl bei einigmail 1.9.9 bleiben bzw. auf PGP ganz verzichten, weil das nun entweder zu kompliziert wird oder nicht mehr sicher ist.

    Ich will alle meine verschlüsselte e-Mails von heute und von vor Jahren unkompliziert lesen können - basta!


    Gruß

    Ch. Hanisch

  • Ich denke es wäre eine zwar einmalig aufwändige Prozedur, aber man könnte diese jetzige Zäsur für eine Kombination von zukunftsfähigen Schritten nutzen, sobald Thunderbird 60 veröffentlicht ist:

    • Neues Thunderbird-Profil erstellen.
    • Alle Accounts in Thunderbird dann mit Maildir statt Mailbox als Speicherformat anlegen.
    • Neuen PGP-Key erstellen und verteilen, falls dieser älter als circa 10 Jahre ist.
    • Die alten PGP-Mails entschlüsseln (mit dem alten Enigmail) und anschließend mit dem neuen PGP-Key wieder verschlüsselt speichern.

    Wie man dabei den Übergang vom alten Profil / alten Thunderbird / altes Enigmail hin zu den neuen Varianten schafft, muss man sich halt überlegen.

  • Immerhin überlegt Patrick Brunschwig, ob man einen Weg für die alten Bestands-PGP-Mails finden kann, um diese auch so weiterhin entschlüsseln zu können, wenn der alte Key kein MDC unterstützt hat.

  • Ich denke, dieses Thema könnte die Lösung sein:

    Die Lösung ist es nicht in allen Fällen. Es beschreibt aber die Ursache, die wie gesagt darin liegt, dass Enigmail zum Schutz vor Efail nun auf MDC kontrolliert. Wie es in den Release Notes steht. GnuPG unterstützt das seit 17 Jahren. Ich meine, Patrick schreibt zurecht:

    Zitat

    and in the light of the severe weaknesses that have been discovered, it's about time to enforce it. We (the OpenPGP community) should have done this already many years ago.


    Es gibt mehrere Wege, das Problem zu lösen.

    1. Bei Enigmail entscheidet man sich, E-Mails ohne MDC nach einer entsprechenden Warnung doch noch zu entschlüsseln. Das kann dann frühestens in einer der nächsten Versionen der Fall sein.
    2. Man entschlüsselt alte E-Mails ohne MDC noch mit einer 1.9.x und speichert die E-Mails entschlüsselt ab. Wem es wichtig ist, die Mails weiterhin verschlüsselt abzuspeichern, der kann die Mails entweder erneut verschlüsseln oder auf einer verschlüsselten Partition speichern.

    Wer CAST5 oder 3DES verwendet hat, sollte die Gelegenheit nutzen und darüber nachdenken, seine Schlüssel anzupassen und neu zu verteilen. Bei einer alten Version zu bleiben, nur um weiterhin mit veralteten Algorithmen zu verschlüsseln, ist nicht zu empfehlen. Das ist ja Vogel-Strauß-Verhalten.


    basta!

    Das hätte ich gleich für den ersten Beitrag gewünscht. Dann hätte ich Bescheid gewusst und mir Zeit sparen können, die ich auch nicht im Überfluss habe. Solche Argumente signalisieren mir Desinteresse an Erklärungen und der Lösung. Da steige ich aus.


    In der Zwischenzeit kam ein neuer Beitrag von Thunder rein, der die genannten Optionen ebenfalls auflistet. Sorry für das doppelte Posting.

  • Kein "normaler" Nutzer wird das verstehen.

    Enigmail ist schon ein wenig benutztes Nischenprodukt, das wird wohl so bleiben bzw. sich verschärfen, wenn man die Anwender derart vor den Kopf stößt. Die wollen funktionierende Software und nicht kryptische Befehle auf der Kommandozeile eintippen.

    Hanisch schrieb:

    Ich will alle meine verschlüsselte e-Mails von heute und von vor Jahren unkompliziert lesen können (...)

    Kann ich gut verstehen. Wichtige Mails (sonst wären sie ja wohl nicht verschlüsselt) plötzlich nicht mehr bzw. nur mit großem Aufwand lesbar?

    Ich hoffe mal, daß sich Patrick das überlegt und es bald eine echte Lösung gibt.

    Grüße, muzel

  • Hallo,

    Ich denke es wäre eine zwar einmalig aufwändige Prozedur, aber man könnte diese jetzige Zäsur für eine Kombination von zukunftsfähigen Schritten nutzen, sobald Thunderbird 60 veröffentlicht ist:

    • Neues Thunderbird-Profil erstellen.
    • Alle Accounts in Thunderbird dann mit Maildir statt Mailbox als Speicherformat anlegen.
    • Neuen PGP-Key erstellen und verteilen, falls dieser älter als circa 10 Jahre ist.
    • Die alten PGP-Mails entschlüsseln (mit dem alten Enigmail) und anschließend mit dem neuen PGP-Key wieder verschlüsselt speichern.

    Wie man dabei den Übergang vom alten Profil / alten Thunderbird / altes Enigmail hin zu den neuen Varianten schafft, muss man sich halt überlegen.

    Das halte ich allerdings für unzumutbar.

    Nachdem man sich jahrelang mühevoll durch den PGP-Dschungel gekämpft und nun eine funktionierende PGP-Kommunikation mit seinen Partnern hat, ist eigentlich der Gipfel der Zumutbarkeit mit einer Aktualisierung der Schlüssel etwa zeitgleich bei allen PGP-Partnern erreicht.


    1) Änderung des veralteten Schlüssels für MDC-Unterstützung bei allen PGP-Partnern

    gpg --edit-key 0xYourKeyId setpref save


    2) Hochladen des aktualisierten eigenen Schlüssels auf den Key-Server

    Enigmail -> Schlüssel verwalten -> Markieren des eigenen Schlüssels ("YourKeyId") -> Schlüsselserver -> Öffentlichen Schlüssel hochladen...


    3) Danach etwas zeitversetzt Aktualisieren des eigenen Schlüsselbundes vom Key-Server bei allen PGP-Partnern

    Enigmail -> Schlüssel verwalten -> Schlüsselserver -> Alle öffentlichen Schlüssel aktualisieren


    4) Wahlweise zusätzlich noch in C:\Users\%USERNAME%\AppData\Roaming\gnupg\gpg.conf bzw. unter Linux ~/.gnupg/gpg.conf die Zeile:

    Code
    1. cipher-algo AES256

    hinzufügen.


    Der richtige Ansatz zur Lösung des Problem sollte sein:

    "Immerhin überlegt Patrick Brunschwig, ob man einen Weg für die alten Bestands-PGP-Mails finden kann, um diese auch so weiterhin entschlüsseln zu können, wenn der alte Key kein MDC unterstützt hat."(Zitat)


    Eine Warnung, den eigenen öffentlichen Schlüssel mit

    gpg --edit-key 0xYourKeyId setpref save

    unbedingt zu aktualisieren und dann an die Partner zu verteilen - statt der derzeitigen Fehlermeldung - wäre meiner Meinung nach zielführend.

    So würde niemand vor den Kopf gestoßen und neuere e-Mails laufen dann ohnehin ohne diese Warnung.


    Und es geht ja auch nur darum, die älteren e-Mails, die ohne MDC verschickt worden sind, im eigenen Archiv jederzeit wieder lesen zu können.

    Diese Forderung ist wohl nicht unbillig, denn bei Beachtung der Warnung tritt das Problem zukünftig nicht mehr auf.


    Gruß

    Ch. Hanisch

    6 Mal editiert, zuletzt von Hanisch ()

  • Vorhin wollte ich in meinem Beitrag noch erwähnen, dass ich über die Komplexität, die sich hier zeigt, enttäuscht bin, weil einige Freunde und ich seit Jahren versuche, andere zur Verschlüsselung zu bewegen.

    Ich habe es dann wieder gelöscht, weil ich festgestellt habe, dass die Aussage in dieser Form nicht stimmt.

    Efail und vor allem die in den ersten Stunden hektische, unsachliche und teilweise falsche Darstellung in den Medien, haben sicherlich Schaden angerichtet. Der wird sich möglicherweise nicht so schnell wieder gutmachen lassen.
    Verschlüsselung ist dadurch aber weder schwieriger geworden noch ist unsicher.

    In einem ersten Gedanken war ich zunächst auch der Meinung, Enigmail sollte eine Funktion erhalten, nach Bestätigung auch E-Mails zu entschlüsseln, die MDC nicht unterstützen.
    Inzwischen bin ich zu dem Schluss gekommen, dass es besser wäre, eine solche Funktion nicht zu implementieren.

    Was sind meine Gründe?

    Die Änderung in Enigmail dienen der Sicherheit der Verschlüsselung. Efail ist nicht wirklich neu. Ähnliche Angriffe wurden bereits in der Vergangenheit durchgeführt. Deshalb hat GnuPG bereits vor 17 Jahren MDC eingeführt. Der Rest der Community hat leider nicht darauf reagiert.


    Jemand, der wirklich so vertrauliche Dokumente per E-Mail versendet, die eine sichere Verschlüsselung zwingend erforderlich machen, der sollte so gut es geht geschützt werden. Enigmail sollte deshalb keine alten, unsichereren Verfahren unterstützen.


    Wenn Enigmail die Verwendung von Nicht-MDC-Algorithmen wie CAST5 und 3DES weiterhin erlauben würde, dann werden vermutlich weitere 17 Jahre vergehen, bis diese Algorithmen endlich verschwunden sein werden. Wenn überhaupt.


    Dieser Faden bestätigt das. Betroffen sind nur Anwender, die oder deren Mailpartner es in all den Jahren nicht geschafft haben, Schlüssel zu verwenden, die MDC unterstützen.


    Ich kann den Ärger um den nun erforderlichen Aufwand gut verstehen. Trotzdem, es ist ein Widerspruch einerseits Vertraulichkeit und Sicherheit zu erwarten, andererseits aber so alte und angreifbare Verfahren einzusetzen. Wenn es die Sicherheit nicht Wert ist, endlich auf geeignete Verfahren umzusteigen, dann kann der Bedarf an Vertraulichkeit nicht so hoch sein.