Page MenuHome GnuPG

GPG OL: Mail clients cannot detect PGP decrypted message as encrypted mail has wrong "Content-Type"
Closed, ResolvedPublic

Description

I just installed gpg4win 2.2.4 and sent an encrypted mail from outlook to kmail
4.13.3. Kmail failed to automatically detect that mails as decrypted and hence
fails
to decrypt the message. By comparing the message sources of that outlook mail
and
another mail that gets decrypted I found the following differences in the
emails'
sources:

Begin: Excerpt of encrypted mail from outlook

Content-Type: multipart/mixed;
boundary="_005_6AFB03C966D5AE4089C8532D1C9DB5580E45CE3BA6ZDE070lenzeco_"
MIME-Version: 1.0
X-Brightmail-Tracker: [..unimportant for that bug..]
X-SpamAssassin: $spamass_status

--_005_6AFB03C966D5AE4089C8532D1C9DB5580E45CE3BA6ZDE070lenzeco_
Content-Type: multipart/alternative;
boundary="_000_6AFB03C966D5AE4089C8532D1C9DB5580E45CE3BA6ZDE070lenzeco_"

--_000_6AFB03C966D5AE4089C8532D1C9DB5580E45CE3BA6ZDE070lenzeco_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

-----BEGIN PGP MESSAGE-----
Version: GnuPG v2

End: Excerpt of encrypted mail from outlook

Begin: Excerpt of encrypted mail from kmail

MIME-Version: 1.0
Content-Type: multipart/encrypted; boundary="nextPart1818673.gpSnp61kLK";
protocol="application/pgp-encrypted"
X-User-Auth: Auth by k@d. through .*.*.***

--nextPart1818673.gpSnp61kLK
Content-Type: application/pgp-encrypted
Content-Disposition: attachment
Content-Transfer-Encoding: 7Bit

Version: 1
--nextPart1818673.gpSnp61kLK
Content-Type: application/octet-stream
Content-Disposition: inline; filename="msg.asc"
Content-Transfer-Encoding: 7Bit

-----BEGIN PGP MESSAGE-----
Version: GnuPG v2

End: Excerpt of encrypted mail from kmail

As you can see, GPG OL fails to set the Content-Type to "multipart/encrypted;
boundary="..."; protocol="application/pgp-encrypted" but uses "multipart/
mixed;"
instead.

Probably those other two "nextParts" are required, too, for automatic detection
and
decryption.

If you need financial support to allocate resources for fixing this, contact
me,
please. (That option is only possible until October 2015!)

Details

Version
2.2.4

Event Timeline

Please find attached two encrypted mails sent via Kmail. Kmail can detect both as
PGP-encrypted even the "Inline-OpenPGP" formatted one. There must be some
critical difference to encrypted mails received from Outlook with GPG OL that
cause outlook mails not to be detected as encrypted.

Please disable "HTML and Text" and use "text only" For formatting thge mails.

werner lowered the priority of this task from High to Normal.Jun 10 2015, 12:47 PM

Yes, that's a confirmed workaround. However, sending HTML-Messages is important
to my business. So the bug remains.

werner lowered the priority of this task from Normal to Low.Jun 10 2015, 5:28 PM

HTML mails are a severe security problem and may render the whole encryption
useless. Thus I downgrade this bug.

I'm sorry but that's just a poor excuse for several reasons:

  • The security issues arising from HTML mails are a totally different attack vectors.
  • Your claim that HTML messages would render encryption useless is wrong unless

there's a severe bug in the encryption/decryption algorithm, that triggers a buffer
overflow when reading the message's text.

  • The purpose of encryption is to hide the message content while the mail is traveling

through the web.

  • Encryption has got to be independent of the encrypted contents. Otherwise, following

your logic, you should drop encryption of attached ZIP, PDF, EXE, and whatever else
files.

As I said at the end of my first comment: I'd like to fund its fixing as that bug is a
real pain when it comes to interoperability across different OS-boxes/mail clients.

Hi Werner,

now I am confused as to what I just found on Wikipedia about "Gpg4win": http://de.wikipedia.org/wiki/PGP/MIME
Quotes from that page [translated to English]:
"PGP/MIME is – just as the old PGP/INLINE – an encoding to mark an email for mail clients [as encrypted]."

"Mail clients supporting that encoding can detect if an email and its attachments are encrypted and/or signed with PGP/GnuPG."

"With PGP/MIME it's possible to encrypt all attachments along with the message which is the default behavior." And which is
also a major usability improvement.

Because other mail clients (except for e.g. Kmail and probably some others, too) do not support that encoding yet comes the
quote that puzzled me:
"Government-funded by the German agency "Bundesamt für Sicherheit in der Informationstechnik" (BSI) the software Gpg4win was
published."

I'd like you to explain why you rated that bug low and talk it down when on the other hand GPG OL - which is shipped as part
of Gpg4win - is supposed to support that encoding type?

IMO that's a very strong hint for an incomplete feature or bug.

Has it something to do with closed-source Outlook itself and that GPG OL is not able to change the "Content-Type"? In that
case rating the bug down is no right as it would never get fixed anyways.

Regards
Robert

The support for OL2010 is pretty limited compared to what gpgol can do
with earlier versions. The Compendium also notes that you should not
use HTML mails. For example in 13.3 (German version):

  Es ist empfehlenswert, Ihr E-Mail-Programm so einzustellen, dass Sie
  E-Mails nur im "Text"-Format und *nicht* im "HTML"-Format
  versenden. Sollten Sie dennoch HTML für signierte oder
  verschlüsselte E-Mails verwenden, können dabei beim Empfänger die
  Formatierungsinformationen verloren gehen, was zum Bruch der
  Signatur führen kann.

Andre: Do you have time to look into this?

This should work. GpgOL 2010 just queries the Plain Text from outlook and
encrypts that.

KMail (Which is my primary mail client and testing client) works fine with such
mails.

Robert, could you send an example mail created by GpgOL that kmail does not decrypt?

To: aheinecke@intevation.de

My keyid is: C97822F5

You can find it attached.

As this is still waiting for info for two years and I can't reproduce with current GpgOL -> Resolved.