That's always a (somewhat) reasonable approach, provided the recipient can deal with the extra work, and the end client doesn't recognize it and try to decrypt anyway; packing in a zip or tgz after encryption should help there.
It's not convenient, however, so the ideal case is (or will be) for the providers of email clients to fix their software to automatically disable HTML by default, block remote assets by default, and block all HTML when any encrypted content is encountered (some already do most of this, c.f. mailpile).
Automatic selection of less vulnerable encryption modes (e.g. AES-CGM) in GPG can help here as well, but that is not a critical item, given that all of the attack vectors are primarily client flaws rather than encryption flaws per-se.
As always, you need to assess your own security exposure and act according to your own needs. For a great many people who use PGP/MIME and/or S/MIME, the encryption is a better-safe-than-sorry item, and they are unlikely to be the target of an entity with enough resources to carry out these kinds of attacks.
For those with real concerns around safety and security, and for whom emails may contain high-value information, the situation warrants much more careful scrutiny.
On 2018-05-14 04:18 PM, Herminio Hernandez, Jr. wrote:
> So it looks like a good way to send secure message is write them as text
> files, encrypt them via GPG and send as attachments. Am I right?
>
> On Mon, May 14, 2018 at 3:52 PM, Joseph Sinclair <plug-discussion@stcaz.net>
> wrote:
>
>> The EFF recommendation is primarily an abundance of caution for the
>> community who use PGP for mail as many such users are at risk of serious
>> and targeted attack.
>> PGP being enabled won't open a threat vector for some other attack.
>> Having it enabled in email may, however, allow a targeted attack to expose
>> the decrypted content of those emails; so for now (if you have very
>> high-value encrypted emails) it may be better to export PGP email and
>> decrypt at the command line for reading in a text editor.
>>
>> TL;DR
>> Overall this is a class of attacks that could expose the plain text of
>> emails encrypted with S/MIME or PGP, but requires enough effort and skill
>> that it's mostly an issue for individuals who are using PGP or S/MIME to
>> defend against serious threats, such as criminal organizations or state
>> actors, and have emails containing sufficient value to justify the level of
>> effort involved.
>> All users should disable HTML in email by default, regardless, as that is
>> a major attack vector that has no known mitigation (and likely never will),
>> HTML may be enabled for individual (unencrypted) messages as needed.
>> Encrypted email should, of course, never be anything other than plain text
>> (with separately encrypted attachments if needed).
>>
>> Below is my (admittedly limited) full assessment for those who might be
>> interested.
>>
>> The vulnerabilities requires two major factors:
>> 1) The attacker must have the original encrypted message (the ciphertext)
>> still encrypted. These are most concerning as Man-in-the-Middle attacks.
>> 2) The client must (generally) have HTML email supported and enabled
>> (note, HTML isn't the only backchannel available, but it's the most likely
>> and by far the easiest to implement).
>>
>> Note that all of these techniques export some amount of the decrypted
>> data, but not a massive amount. Somewhere between 4 and 200 bytes. They
>> can be repeated, however, within a final multipart MIME email to obtain the
>> full text.
>>
>> How it works, in short form:
>> If you have HTML enabled on view, the attacker can send you a message in
>> HTML format with the ciphertext buried within the HTML (e.g. inside the
>> href attribute of a img tag), and use url packing (putting tracking text in
>> a URL after the resource path) to send that text to a server. The client
>> will happily decrypt the contents, then attempt to access the url, sending
>> the decrypted data to the server as part of the request.
>> If you have one of the HTML email clients (e.g. most webmail clients) that
>> allow script within the email, then a script could easily send the *entire*
>> decrypted content to the server, and then display *only* that to the user;
>> successfully hiding its tracks while obtaining the full decrypted message.
>> Webmail clients should probably never be used with PGP or S/MIME.
>>
>> What the attacker does is grab the encrypted message, modify it to take
>> advantage of one of the discussed techniques, and then forward it on to the
>> intended recipient.
>> In the simplest case, the attacker just wraps the content in properly
>> structured HTML (ideally with script) and adjusts the MIME structure, then
>> send it on. If HTML is enabled, this can be enough.
>> If a more advanced approach is required (and script isn't available), then
>> the data can be restructured in several ways using flaws in specific block
>> encryption modes (specifically CBC and CFB) to obtain small amounts of data
>> in each MIME part; repeating the attack enough times to get most or all of
>> the data (up to around 500 MIME parts). The message looks funny, and might
>> be suspicious, but it still has a decent chance of working.
>> With even more effort, a non-HTML backchannel might be used, something
>> like MIME external data blocks and DNS sniffing, or PGP key lookups, but
>> the amount of data obtained in this way will be quite limited.
>>
>> GPG includes certain mechanisms to prevent the more difficult attacks
>> against the OpenPGP specification, although it cannot do much about a leaky
>> client. Not all clients enable those features or respond to reported
>> security issues properly, however, so while GPG is (or can be) secure, its
>> use in email may not be, depending on the client.
>> Some mail gateways that apply encryption at the gateway are vulnerable,
>> although most can be configured to be secure, and some are secure in the
>> default configuration (details for these are not provided, of course).
>>
>> On 2018-05-14 01:58 PM, Herminio Hernandez, Jr. wrote:
>>> So this why the EFF is recommending this
>>> https://www.eff.org/deeplinks/2018/05/disabling-pgp-thunderbird-enigmail
>>>
>>> On Mon, May 14, 2018 at 1:24 PM, der.hans <PLUGd@lufthans.com> wrote:
>>>
>>>> moin moin,
>>>>
>>>> lots of news about "new" PGP and S/MIME handling security issues.
>>>>
>>>> Considering GnuPG addressed it 15 years ago, it doesn't seem to be new
>> :)
>>>>
>>>> Also, email clients automatically displaying remote content has never
>>>> been safe.
>>>>
>>>> Summary seems to be:
>>>>
>>>> 1. Using text mail rather than html mail mitigates one of the disclosed
>>>> issues.
>>>>
>>>> 2. Disabling old ciphers or having a mail client that properly handles
>>>> decryption warnings and/or sanitizes messages will work for the other.
>>>>
>>>> See mailpile's response for the latter.
>>>>
>>>> https://lists.gnupg.org/pipermail/gnupg-users/2018-May/060315.html
>>>>
>>>> https://www.mailpile.is/blog/2018-05-14_PGP_Security_Alert.html
>>>>
>>>> One good thing to come out of this is that I now know about mailpile :)
>>>>
>>>> ciao,
>>>>
>>>> der.hans
>>>> --
>>>> # https://www.LuftHans.com https://www.PhxLinux.org
>>>> # Eternal vigilance is the price of liberty. -- Thomas Jefferson
>>>> ---------------------------------------------------
>>>> PLUG-discuss mailing list - PLUG-discuss@lists.phxlinux.org
>>>> To subscribe, unsubscribe, or to change your mail settings:
>>>> http://lists.phxlinux.org/mailman/listinfo/plug-discuss
>>>
>>>
>>>
>>> ---------------------------------------------------
>>> PLUG-discuss mailing list - PLUG-discuss@lists.phxlinux.org
>>> To subscribe, unsubscribe, or to change your mail settings:
>>> http://lists.phxlinux.org/mailman/listinfo/plug-discuss
>>>
>>
>>
>> ---------------------------------------------------
>> PLUG-discuss mailing list - PLUG-discuss@lists.phxlinux.org
>> To subscribe, unsubscribe, or to change your mail settings:
>> http://lists.phxlinux.org/mailman/listinfo/plug-discuss
>>
>
>
>
> ---------------------------------------------------
> PLUG-discuss mailing list - PLUG-discuss@lists.phxlinux.org
> To subscribe, unsubscribe, or to change your mail settings:
> http://lists.phxlinux.org/mailman/listinfo/plug-discuss
>
---------------------------------------------------
PLUG-discuss mailing list -
PLUG-discuss@lists.phxlinux.org
To subscribe, unsubscribe, or to change your mail settings:
http://lists.phxlinux.org/mailman/listinfo/plug-discuss
(text/plain)
