TB entschlüsselt bei alten (Inline-verschlüsselten) Mails nur eingehende

    • Thunderbird-Version 78.10.0 (32-Bit)
    • Betriebssystem + Version: Linux Debian 10
    • PGP-Software / PGP-Version: gpg 2.2.12-1+deb10u1
    • Eingesetzte Antivirensoftware: keine

    Hallo,

    beim Stöbern in meinem Mailarchiv (ab 2007) bin ich bei alten, Inline-verschlüsselten Mails auf ein merkwürdiges Verhalten gestoßen. In einem längeren Thread werden nur eingehende Mails nach Eingabe der Passphrase entschlüsselt und angezeigt. Bei allen ausgehenden Mails, die mit den gleichen Schlüsseln verschlüsselt sind, wird das Passwort zwar abgefragt, danach erhalte ich aber:

    Im Klartext:

    Wenn ich den Inline-Block der ausgehenden Mails:[box]

    -----BEGIN PGP MESSAGE-----

    Charset: ISO-8859-15

    Version: GnuPG v1.4.6 (GNU/Linux)

    …

    -----END PGP MESSAGE-----[/box]

    als mail_out.asc abspeichere, kann ich ihn mit gpg problemlos entschlüsseln (der Klartext landet dann in der Datei mail_out).

    Das Problem liegt also nicht am Schlüssel, sondern muß mit dem Verhalten von TB zusammenhängen. Nach dem Aktivieren des Debug-Logs[1] erhalte ich folgende Ausgaben (irrelevante Einträge gelöscht):

    Eingehende Mail:[box]

    17:09:21.395 rnp-cryptoAPI.js: decrypt()

    17:09:42.073 decryption.jsm: decryptMessage: decryption finished

    17:09:42.079 enigmailMessengerOverlay.js: messageParseCallback: newSignature=''

    17:09:42.080 enigmailMsgHdrViewOverlay.js: this.updateHdrIcons: exitCode=-1, statusFlags=131204, extStatusFlags=0, keyId=01234567890ABCDEF, userId=, undefined

    17:09:42.082 keyRing.jsm: getKeyById: 01234567890ABCDEF

    17:09:42.086 uris.jsm: rememberEncryptedUri: uri=mailbox-message://nobody@Local%20Folders/<ordner>#1

    17:09:42.088 enigmailMsgHdrViewOverlay.js: this.updateMsgDb

    17:09:42.089 enigmailMessengerOverlay.js: getDecryptedMessage: message/rfc822, false

    17:09:42.166 enigmailMessengerOverlay.js: movePEPsubject:[/box]

    Ausgehende Mail:[box]

    17:10:01.727 rnp-cryptoAPI.js: decrypt()

    17:10:02.529 decryption.jsm: decryptMessage: decryption finished

    17:10:02.530 enigmailMessengerOverlay.js: messageParseCallback: newSignature=''

    17:10:02.531 enigmailMsgHdrViewOverlay.js: this.updateHdrIcons: exitCode=301989894, statusFlags=65792, extStatusFlags=0, keyId=, userId=, undefined

    17:10:02.534 enigmailMsgHdrViewOverlay.js: this.updateMsgDb[/box]

    Die keyId 01234567890ABCDEF ist die des Absenders der eingehenden Mail. Warum bei der ausgehenden Mail überhaupt kein Schlüssel erkannt wird (obwohl die Passphrase abgefragt wird!) geht daraus leider auch nicht hervor. Mit exitCode=301989894 kann ich nichts anfangen.

    Kann jemand mit Inline-verschlüsselten Mails das Verhalten nachvollziehen?

    [1] https://wiki.mozilla.org/Thunderbird:OpenPGP#OpenPGP_log

    Zitat von B. Mueller

    Kann jemand mit Inline-verschlüsselten Mails das Verhalten nachvollziehen?

    Ich kann diese Mails alle lesen. Viele habe ich nicht mehr, weil ich sie entschlüsselt archiviert habe. Aber ich habe ein paar Testmails aus 2018 gefunden. Die werden allen entschlüsselt.

    Nur überflogen: Auffällig ist, dass bei dir im DebugLog von Enigmail die Rede ist.

    Wer wenig oder gar nichts kann, schiebt's auf den Antiviruskram.

    (Compuzius, Buch 5)

    Zitat von Susi to visit

    Auffällig ist, dass bei dir im DebugLog von Enigmail die Rede ist.

    Danke für den Hinweis, in der prefs.js bzw. user.js waren noch Überreste des Addons Enigmail. Nach dem Zurücksetzen dieser Schlüssel und Neustart von TB gibt es jetzt nur noch einen in der prefs.js (mit der Standardeinstellung):[box]

    temp.openpgp.hoursPerWeekEnigmailIsOn Standard Integer 40[/box]

    Im Debug-Log sind jetzt die beiden Schlüssel-IDs (die des Empfängers und meine) hinzugekommen:

    [box]

    20:47:26.933 rnp-cryptoAPI.js: decrypt()

    20:47:43.099 decryption.jsm: decryptMessage: decryption finished

    20:47:43.101 enigmailMessengerOverlay.js: messageParseCallback: newSignature=''

    20:47:43.102 enigmailMsgHdrViewOverlay.js: this.updateHdrIcons: exitCode=301989894, statusFlags=65792, extStatusFlags=0, keyId=, userId=, undefined

    20:47:43.104 enigmailMsgHdrViewOverlay.js: this.updateMsgDb

    20:47:50.234 keyRing.jsm: getKeyById: 01234567890ABCDEF

    20:47:50.240 keyRing.jsm: getKeyById: ABCDEF01234567890[/box]

    Am Ergebnis hat sich leider nichts geändert - nach wie vor die gleiche Meldung. Die enigmail* Einträge im Log haben sich auch nicht geändert und basieren wohl noch auf dem Quellcode von TB 78.

    Ich habe die Logs bei mir nun ebenfalls aktiviert. Die Logs sehen ähnlich aus. Dass darin Enigmail auftaucht, hat offenbar nichts mit der ehemaligen Erweiterung zu tun. Man hat wohl die Bezeichnung für die Code-Teile, die nun integriert wurden, beibehalten. Daran liegt es also nicht.

    Ist der für die alten Mails benötigte Schlüssel noch dein derzeit aktiv benutzter Schlüssel, also der, den du auch als externen Schlüssel im Thunderbird eingebunden hast? Oder ist das ein älterer, der nur noch in der Schlüsselverwaltung des OS zur Verfügung steht?

    Grad noch was: Hast du zusätzlich auch die RNP-Log aktiviert? Sieht man darin vielleicht etwas?

    Wer wenig oder gar nichts kann, schiebt's auf den Antiviruskram.

    (Compuzius, Buch 5)

    Zitat von Susi to visit

    Ist der für die alten Mails benötigte Schlüssel noch dein derzeit aktiv benutzter Schlüssel, also der, den du auch als externen Schlüssel im Thunderbird eingebunden hast? Oder ist das ein älterer, der nur noch in der Schlüsselverwaltung des OS zur Verfügung steht?

    Es ist ein alter, nicht mehr benutzter Schlüssel von 2007, Nachfolger eines noch älteren IDEA-Schlüssels aus den 90er Jahren (ver. 2.6.x), der dann 2013, als die Inline-Verschlüsselung obsolet wurde und ein Wechsel zu Posteo stattfand, von dem heute noch gültigen Schlüssel abgelöst wurde. Alle Schlüsselpaare werden von gpg(-agent) verwaltet.

    Da mit dem Ende der Inline-Verschlüsselung auch der Schlüssel selbst wechselte, tritt das Problem halt nur mit diesem einen Schlüssel auf.

    Das RNP-Log habe ich jetzt mal aktiviert. Es liefert folgendes beim Versuch zu entschlüsseln:

    Eingehende Mail (ok):[box]

    [init_encrypted_src() /build/thunderbird-wRTaZk/thunderbird-78.10.0/comm/third_party/rnp/src/librepgp/stream-parse.cpp:2087] failed to obtain decrypting key or password

    [signed_src_finish() /build/thunderbird-wRTaZk/thunderbird-78.10.0/comm/third_party/rnp/src/librepgp/stream-parse.cpp:1023] signer's key not found[/box]

    Ausgehende Mail (Fehlermeldung):[box]

    [init_encrypted_src() /build/thunderbird-wRTaZk/thunderbird-78.10.0/comm/third_party/rnp/src/librepgp/stream-parse.cpp:2087] failed to obtain decrypting key or password

    [mem_dst_write() /build/thunderbird-wRTaZk/thunderbird-78.10.0/comm/third_party/rnp/src/librepgp/stream-common.cpp:998] attempt to alloc more then allowed[/box]

    Bei dem fehlenden Schlüssel handelt es sich um den öffentlichen Schlüssel des Empfängers, den ich leider nicht mehr habe. Die letzte Zeile deutet für mich auf ein Problem beim RNP Backend hin - warum auch immer.

    Wie gesagt, für ein- und ausgehende Mails wurden dieselben Schlüssel verwendet.

    Tut mit leid. Da kann ich auch nur spekulieren. Ich weiß z.B. nicht, ob der Thunderbird auch in deinem Fall, bei Nutzung externer Schlüssel, die Entschlüsselung selbst mit OpenPGP durchführt oder ob er sie von GnuPG durchführen lässt. Ich vermute, dass er sich nur den Schlüssel holt und dann selbst entschlüsselt.

    Da du für den ganz alten Schlüssel IDEA angesprochen hast, ich weiß auch nicht aus dem Kopf, welche Algorithmen von OpenPGP unterstützt werden. Solltest für den fraglichen Schlüssel auch einen Exoten verwendet haben, könnte das der Grund sein. Da würde ich zwar eine andere Fehlermeldung erwarten, aber mit diesen Meldungen ist das ja immer so eine Sache.

    Und wieder etwas vergessen:

    Zitat von B. Mueller

    der dann 2013, als die Inline-Verschlüsselung obsolet wurde und ein Wechsel zu Posteo stattfand, von dem heute noch gültigen Schlüssel abgelöst wurde.

    Woher stammt die Information, PGP/INLINE sei obsolet? Thunderbird 78 bietet es für die Verschlüssleung nicht mehr an. Bis zur 68 konnte man es aber in Enigmail auswählen. Andere Clients können das bis heute, manche sogar ausschließlich. Thunderbird 78 entschlüsselt inline auch nach wie vor korrekt.

    Wer wenig oder gar nichts kann, schiebt's auf den Antiviruskram.

    (Compuzius, Buch 5)

    Einmal editiert, zuletzt von Susi to visit (26. Mai 2021 um 14:21)

    Zitat von Susi to visit

    Solltest für den fraglichen Schlüssel auch einen Exoten verwendet haben, könnte das der Grund sein.

    Exotisch ist der betreffende Schlüssel sicher nicht: dsa1024/elg4096, die neuen sind: dsa3072/elg4096. IDEA war damals halt Stand der Technik.

    Ich warte mal, wie der Nachfolger damit umgehen kann … https://sequoia-pgp.org/

    Zitat von Susi to visit

    Woher stammt die Information, PGP/INLINE sei obsolet?

    Obsolet für mich im Sinne von: «nicht mehr gebräuchlich». Nicht viele Mailprogramme beherrschten damals PGP/MIME.

    Zitat von B. Mueller

    Ich warte mal, wie der Nachfolger damit umgehen kann

    Da musst du nicht warten. Hier gab's neulich schon einen Post zum Octopus. Den gibt es meines Wissens bereits seit April. Damit bekämst du einige der alten Features wieder, u.a. auch die Schlüsselverwaltung über den agent.

    Apropos, die Frage lässt sich nicht vermeiden: Hast du einmal ausprobiert, ob deine alten Mails korrekt entschlüsselt werden, wenn die die Schlüssel wie vorgesehen, vom Thunderbird verwalten lässt?

    Wer wenig oder gar nichts kann, schiebt's auf den Antiviruskram.

    (Compuzius, Buch 5)

    Zitat von Susi to visit

    Hast du einmal ausprobiert, ob deine alten Mails korrekt entschlüsselt werden, wenn die die Schlüssel wie vorgesehen, vom Thunderbird verwalten lässt?

    Nein, das zweimalige Umstellen tue ich mir nicht an. Mit den eingehenden Mails gibt es ja kein Problem.

    Dabei hast du jetzt doch Übung. :mrgreen:

    Ausschließen würde ich jedenfalls nicht, dass genau dort die Ursache liegt.

    Eine Frage von oben hast du noch nicht abschließend beantwortet:

    Zitat von Susi to visit

    Ist der für die alten Mails benötigte Schlüssel noch dein derzeit aktiv benutzter Schlüssel, also der, den du auch als externen Schlüssel im Thunderbird eingebunden hast?

    Hast du den alten Schlüssel als externen Schlüssel im Thunderbird eingetragen?

    Wer wenig oder gar nichts kann, schiebt's auf den Antiviruskram.

    (Compuzius, Buch 5)

    Zitat von Susi to visit

    Hast du den alten Schlüssel als externen Schlüssel im Thunderbird eingetragen?

    Klar - hatte ich. Die alte Adresse als zusätzlichen Alias und dann die restlichen Einträge mit der richtigen Schlüssel-ID wie für die anderen Aliases. Das hat an dem Verhalten aber nichts geändert, das war vorher auch schon so.

    Ist jetzt auch klar - diese Einträge gelten für neue Mails mit einem Alias als Absender und verknüpftem Schlüssel.

    Dass es sich bei dieser Adresse um einen zusätzlichen Alias handelt, hattest du bisher gar nicht erwähnt. Damit kommen beide deiner durchaus strittigen Änderungen ins Spiel.

    Ob darin der Grund liegt, wissen wir natürlich nicht. Es sind halt gleich zwei deutliche Unterschiede zu der vorgesehenen Standardinstallation. Da das Problem bei mir nicht auftritt, ist ein Verdacht in dieser Richtung zumindest nicht einfach so von der Hand zu weisen. Das sollte man untersuchen.

    Ich hatte eigentlich vor das Problem am Wochenende mit abgelaufenen Schlüsseln nachzustellen. Deine Umgebung weicht mir aber nun doch zu sehr von der Sollkennlinie ab. Beide deiner Änderungen nachzubauen ist mir zu aufwendig. Zumal auch das Wetter ab Sonntag wieder besser werden soll.

    Wer wenig oder gar nichts kann, schiebt's auf den Antiviruskram.

    (Compuzius, Buch 5)

    Zitat von Susi to visit

    Dass es sich bei dieser Adresse um einen zusätzlichen Alias handelt, hattest du bisher gar nicht erwähnt.

    Bei der alten Adresse handelt es sich nicht um einen Alias, ich hatte sie versuchsweise nur so behandelt, da das Konto nicht mehr existiert.

    Zitat von Susi to visit

    Ich hatte eigentlich vor das Problem am Wochenende mit abgelaufenen Schlüsseln nachzustellen.

    Das wäre dann noch ein weiterer Unterschied - ich habe keine abgelaufenen Schlüssel. Wenn ich mal komplett auf mein 64 Bit System umgestiegen bin, werde ich die «octopus-librnp» testen und über das Ergebnis berichten.

    Zitat von B. Mueller

    Bei der alten Adresse handelt es sich nicht um einen Alias, ich hatte sie versuchsweise nur so behandelt, da das Konto nicht mehr existiert.

    Das ändert einiges. Diese Kleinigkeit hattest du bisher gar nicht erwähnt. Oder ich habe sie übersehen. In Beitrag Nummer #5 erwähnst du zwar einen Wechsel zu Posteo, aber dass das besagte Konto gar nicht mehr existiert und du es als Alias eines anderen eingerichtet hast, geht daraus nicht so klar hervor.

    Wenn du dabei nach der Methode vorgangen bist, über die wir schon neulich uneins waren, wundert es mich nicht, dass es nicht klappt. Im Gegenteil, ich denke genau das ist zu erwarten. Meiner Meinung nach ist das Problem eindeutig hausgemacht.

    Wer wenig oder gar nichts kann, schiebt's auf den Antiviruskram.

    (Compuzius, Buch 5)

    Dann solltest du dich bitte mal klarer ausdrücken. Du hast geschrieben:

    Zitat von B. Mueller

    Klar - hatte ich. Die alte Adresse als zusätzlichen Alias und dann die restlichen Einträge mit der richtigen Schlüssel-ID wie für die anderen Aliases. Das hat an dem Verhalten aber nichts geändert, das war vorher auch schon so.

    Da kann man nur raten, was vorher meint. Vor dem Workaround mit der Schlüsselverwaltung? Vor deinem Hack mit Aliasen? Vor Thunderbird 78, also noch mit Enigmail?

    Ich mag das gar nicht weiter ausdiskutieren. Wir wissen ja beide, wie es enden wird. Ich werde weiterhin sagen, "deine Basteleien sind Mist" und allen anderen raten, das ja nicht nachzumachen. Du wirst sie weiter verteidigen.

    Du wirst irgendwann schreiben "wer Verschlüsselung ernst nimmt, ...". Ich werde antworten "... der macht so etwas nicht." oder "... der verschlüsselt auch seine anderen Daten.".

    Das können wir uns ersparen. Ich gebe mich damit zufrieden, dass ich deine Probleme nicht habe.

    Wer wenig oder gar nichts kann, schiebt's auf den Antiviruskram.

    (Compuzius, Buch 5)

    Weitere Analyse und Erkenntnis …

    • den Inline-Block der eingehenden Mail nochmal als «ein.asc» und den der ausgehenden Mail als «aus.asc» gespeichert
    • dann nochmals mit gpg überprüft

    gpg -nv ./ein.asc[box]

    gpg: WARNING: Kein Kommando angegeben. Versuche zu raten was gemeint ist ...

    gpg: ASCII-Hülle: Version: 6.5.8

    gpg: ASCII-Hülle: Comment: Better safe than sorry

    gpg: Öffentlicher Schlüssel ist 0x0123456789ABCDEF

    gpg: Öffentlicher Schlüssel ist 0x89ABCDEF01234567

    gpg: der Unterschlüssel 0x89ABCDEF01234567 wird anstelle des Hauptschlüssels 0x9ABCDEF012345678 verwendet

    gpg: pinentry launched (8836 gnome3 1.1.0 /dev/pts/2 xterm-256color :0.0)

    gpg: verschlüsselt mit RSA Schlüssel, ID 0x0123456789ABCDEF

    gpg: der Unterschlüssel 0x89ABCDEF01234567 wird anstelle des Hauptschlüssels 0x9ABCDEF012345678 verwendet

    gpg: verschlüsselt mit 4096-Bit ELG Schlüssel, ID 0x89ABCDEF01234567, erzeugt 2007-01-25

    "Vorname Name <[email='user@example.com'][/email]>"

    gpg: AES256 verschlüsselte Daten

    gpg: Ursprünglicher Dateiname=''

    gpg: Signatur nach alter (PGP 2.x) Art

    gpg: Signatur vom Mo, 2007-05-07 12:33:22 CEST

    gpg: mittels RSA-Schlüssel 0x0123456789ABCDEF

    gpg: Signatur kann nicht geprüft werden: No public key[/box]

    Kein Problem, «./ein» enthält den entschlüsselten Klartext!

    gpg -nv ./aus.asc[box]

    gpg: WARNING: Kein Kommando angegeben. Versuche zu raten was gemeint ist ...

    gpg: ASCII-Hülle: Charset: ISO-8859-15

    gpg: ASCII-Hülle: Version: GnuPG v1.4.6 (GNU/Linux)

    gpg: Öffentlicher Schlüssel ist 0x0123456789ABCDEF

    gpg: Öffentlicher Schlüssel ist 0x89ABCDEF01234567

    gpg: der Unterschlüssel 0x89ABCDEF01234567 wird anstelle des Hauptschlüssels 0x9ABCDEF012345678 verwendet

    gpg: pinentry launched (9035 gnome3 1.1.0 /dev/pts/2 xterm-256color :0.0)

    gpg: verschlüsselt mit RSA Schlüssel, ID 0x0123456789ABCDEF

    gpg: der Unterschlüssel 0x89ABCDEF01234567 wird anstelle des Hauptschlüssels 0x9ABCDEF012345678 verwendet

    gpg: verschlüsselt mit 4096-Bit ELG Schlüssel, ID 0x89ABCDEF01234567, erzeugt 2007-01-25

    "Vorname Name <[email='user@example.com'][/email]>"

    gpg: 3DES verschlüsselte Daten

    gpg: Ursprünglicher Dateiname=''

    gpg: WARNUNG: Botschaft wurde nicht integritätsgeschützt (integrity protected)

    gpg: Tip: Falls diese Botschaft vor dem Jahr 2003 erzeugt wurde, so wird es

    vermutlich eine legitime Botschaft sein. Die kann vermutet werden, da

    vor diesem Zeitpunkt ein Integritätsschutz nur selten verwendet wurde.

    gpg: Mit der Option '--ignore-mdc-error' kann trotzdem entschlüsselt werden.

    gpg: Entschlüsselungs-Fehler erzwungen![/box]

    Trotz Fehlermeldung enthält «./aus» den entschlüsselten Klartext!

    gpg -nv --ignore-mdc-error ./aus.asc[box]

    gpg: WARNING: Kein Kommando angegeben. Versuche zu raten was gemeint ist ...

    gpg: ASCII-Hülle: Charset: ISO-8859-15

    gpg: ASCII-Hülle: Version: GnuPG v1.4.6 (GNU/Linux)

    gpg: Öffentlicher Schlüssel ist 0x0123456789ABCDEF

    gpg: Öffentlicher Schlüssel ist 0x89ABCDEF01234567

    gpg: der Unterschlüssel 0x89ABCDEF01234567 wird anstelle des Hauptschlüssels 0x9ABCDEF012345678 verwendet

    gpg: pinentry launched (9135 gnome3 1.1.0 /dev/pts/2 xterm-256color :0.0)

    gpg: verschlüsselt mit RSA Schlüssel, ID 0x0123456789ABCDEF

    gpg: der Unterschlüssel 0x89ABCDEF01234567 wird anstelle des Hauptschlüssels 0x9ABCDEF012345678 verwendet

    gpg: verschlüsselt mit 4096-Bit ELG Schlüssel, ID 0x89ABCDEF01234567, erzeugt 2007-01-25

    "Vorname Name <[email='user@example.com'][/email]>"

    gpg: 3DES verschlüsselte Daten

    gpg: Ursprünglicher Dateiname=''

    Datei './aus' existiert bereits. Überschreiben (j/N)? n

    Neuen Dateinamen eingeben: ./aus_2

    gpg: WARNUNG: Botschaft wurde nicht integritätsgeschützt (integrity protected)[/box]

    Kein Unterschied zwischen «./aus» und «./aus_2»!

    Ein weiterer Versuch:

    Diesmal habe ich der eingehenden Mail den Inline-Block der ausgehenden Mail «untergeschoben» und umgekehrt. Wie erwartet, wird jetzt die ausgehende Mail fehlerfrei entschlüsselt, während die eingehende Mail die Fehlermeldung von oben produziert.

    Fazit:

    Das Problem liegt nicht an der Schlüsselverwaltung oder an den Adressen, sondern tiefer:[box]

    gpg: WARNUNG: Botschaft wurde nicht integritätsgeschützt (integrity protected)

    gpg: Tip: Falls diese Botschaft vor dem Jahr 2003 erzeugt wurde, so wird es

    vermutlich eine legitime Botschaft sein. Die kann vermutet werden, da

    vor diesem Zeitpunkt ein Integritätsschutz nur selten verwendet wurde.

    gpg: Mit der Option '--ignore-mdc-error' kann trotzdem entschlüsselt werden.[/box]

    Während gpg problemlos damit umgehen kann, liefert OpenPGP in Thunderbird eine irreführende Fehlermeldung und verweigert die Entschlüsselung!

    Einmal editiert, zuletzt von B. Mueller (29. Mai 2021 um 21:43)

  • Community-Bot 3. September 2024 um 20:50

    Hat das Thema geschlossen.