[Gpg4win-devel] efail -> improvements
Andre Heinecke
aheinecke at intevation.de
Tue May 15 10:07:58 CEST 2018
Hi,
On Tuesday, May 15, 2018 8:47:38 AM CEST Bernhard Reiter wrote:
> On an email just send to gnupg-devel@
> I'm suggesting to change GnuPG and frontends
> to not show any contents, unless there is integrity protection by either
>
> > a) MDC
> > b) AEAD
> > c) a signature over the whole contents from someone where it has been
> > encrypted to (if this is feasable to detect).
>
> We should change all Gpg4win frontends (like GpgOL, Kleo, GpgEX, GPA)
> to honor the warnings and error messages that GnuPG already shows.
We use GPGME and GPGME honors GnuPG's warnings and error messages. To be
honest I didn't really know about the importance of MDC when implementing
decryption in GpgOL. But this shows again that as a frontend developer using
GPGME makes it easy to stay secure as it just "does the right thing".
For Outlook 2007 and 2003 I think that the Problem is that back then GPGME was
not used and the MDC Error got lost in communication through the middle man.
(GPA / Kleopatra)
Please note that file encryption (Kleo or GPA) efail is not an issue and GpgEX
does only call Kleo or GPA.
For S/MIME and GpgOL I think that showing only valid signed content is
unfeasible. Even without the restriction that it should be signed by someone
it is encrypted to.
There is just too much that could go wrong. You are offline, CRL / OCSP not
available. You don't trust the root ca of the sender. A sender want's to send
something anonymously. There are incompatible implementations. There was a
technical problem. etc.
Encryption is already to tricky and we should not make it more difficult to view
encrypted data. I think that such a restriction would loose us users which
will rather send stuff unencrypted and as such would lower the security.
Remember that as far as we know[1], the attacks rely on dynamic HTML features
(e.g. loading of images) and this is generally a very bad Idea, especially for
crypto mails. I rather think we should look into it if we can disable this for
crypto, especially S/MIME mails first. Or at least show a warning if we detect
that this is enabled in Outlook.
So my improvements for Gpg4win would be:
- Remove the vulnerable Outlook 2003 and 2007 support.
- Check if automatic loading of external data is enabled and warn when S/MIME
is decrypted.
- Try to disable loading of external data when S/MIME is decrypted.
Best Regards,
Andre
[1]: There are unclear and vague hints in the paper about a CRL exfiltraction
channel. We do not see any problem there and do not think that it is possible
to exploit it, but we asked the authors to clarify.
--
Andre Heinecke | ++49-541-335083-262 | http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabrück | AG Osnabrück, HR B 18998
Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.wald.intevation.org/pipermail/gpg4win-devel/attachments/20180515/17295595/attachment.asc>
More information about the Gpg4win-devel
mailing list