avoiding metadata leaks when handling S/MIME-signed mail in GMime and other tools that use GnuPG

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

avoiding metadata leaks when handling S/MIME-signed mail in GMime and other tools that use GnuPG

Daniel Kahn Gillmor-7
Hi GMime and GnuPG developers--

sorry for the cross-posting!  coordinating this kind of thing
cross-project is tough.

I recently learned that default handling of signed S/MIME mail with
GnuPG causes an inherent metadata leak about the user's activity:

    https://dev.gnupg.org/T3348#110132

As a MUA developer, I'd like my MUA to simply handle as much crypto as
it can on the user's behalf automatically, correctly and silently,
without needing any special configuration or asking the user to make any
tough tradeoffs that they might object to.

What kinds of tradeoffs are objectionable?  Performance tradeoffs are
probably OK, since they're user-visible, and can be mitigated by
disabling crypto.  But metadata leakage by default seems really
problematic, because (a) it is invisible to the user, and (b) once done,
it cannot be undone.

So my question for GMime and GnuPG developers is how a MUA that uses
GMime should approach this.  Given that GMime relies on GnuPG, and GnuPG
basically says "if you process S/MIME mail, you'll leak metadata", what
is the best way to instruct GMime to say "handle as much cryptographic
mail as you can without leaking metadata"?

GMime 3 has greatly simplified its crypto handling interface, and it has
moved fully to GPGME on the backend, which i appreciate.  However, i
think the interface is now so clean that i don't know how to either:

 * tell GMime to disable crl checks

or

 * tell GMime not to verify S/MIME signatures at all

Either of these methods would address the default metadata leakage
concern, but the first choice provides more functionality to the user.

i note that GPGME offers gpgme_set_offline(), which tells it to avoid
talking to the network entirely.  Maybe that can be exposed by GMime
somehow?

i don't think invoking gpgme_set_offline(true) would break other uses of
GPGME inside GMime or any other sensible MUA, but if there's a fear that
it does, i'd like to hear about it.

Note: i'm perfectly happy to allow the user to override this choice if
they *want* to leak metadata, but i don't think that my MUA should do
that to the user by default.

I'm willing to write patches if there is a reasonable plan forward.

Any suggestions?

    --dkg

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

signature.asc (847 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [gmime-devel] avoiding metadata leaks when handling S/MIME-signed mail in GMime and other tools that use GnuPG

Jeffrey Stedfast-3
Hi Daniel & GnuPG devs,

On 2/2/2018 12:48 PM, Daniel Kahn Gillmor wrote:

> Hi GMime and GnuPG developers--
>
> sorry for the cross-posting!  coordinating this kind of thing
> cross-project is tough.
>
> I recently learned that default handling of signed S/MIME mail with
> GnuPG causes an inherent metadata leak about the user's activity:
>
>      https://dev.gnupg.org/T3348#110132
>
> As a MUA developer, I'd like my MUA to simply handle as much crypto as
> it can on the user's behalf automatically, correctly and silently,
> without needing any special configuration or asking the user to make any
> tough tradeoffs that they might object to.
>
> What kinds of tradeoffs are objectionable?  Performance tradeoffs are
> probably OK, since they're user-visible, and can be mitigated by
> disabling crypto.  But metadata leakage by default seems really
> problematic, because (a) it is invisible to the user, and (b) once done,
> it cannot be undone.
>
> So my question for GMime and GnuPG developers is how a MUA that uses
> GMime should approach this.  Given that GMime relies on GnuPG, and GnuPG
> basically says "if you process S/MIME mail, you'll leak metadata", what
> is the best way to instruct GMime to say "handle as much cryptographic
> mail as you can without leaking metadata"?
>
> GMime 3 has greatly simplified its crypto handling interface, and it has
> moved fully to GPGME on the backend, which i appreciate.  However, i
> think the interface is now so clean that i don't know how to either:
>
>   * tell GMime to disable crl checks

I'd be willing to add an API to disable CRL checks if there's a way I
can pass that along to gpgme.

>
> or
>
>   * tell GMime not to verify S/MIME signatures at all

Willing to add an API for this as well (although I guess it's not
necessary if an API to disable CRL checks is added?)

>
> Either of these methods would address the default metadata leakage
> concern, but the first choice provides more functionality to the user.
>
> i note that GPGME offers gpgme_set_offline(), which tells it to avoid
> talking to the network entirely.  Maybe that can be exposed by GMime
> somehow?

Absolutely.

>
> i don't think invoking gpgme_set_offline(true) would break other uses of
> GPGME inside GMime or any other sensible MUA, but if there's a fear that
> it does, i'd like to hear about it.

Well, I suppose that, like S/MIME signature verification, it would also
disable PGP key-server lookups?

It might be best if there was a way to disable CRL checks on a per
gpgme_ctx_t basis as opposed to globally, but I can have GMime use the
global option until such an option exists (note: might be racey if you
try and verify signatures on multiple threads).

I'll wait for the GnuPG/GPGME devs to comment before making changes to
GMime.

Jeff


_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Reply | Threaded
Open this post in threaded view
|

Re: [gmime-devel] avoiding metadata leaks when handling S/MIME-signed mail in GMime and other tools that use GnuPG

Daniel Kahn Gillmor-7
On Fri 2018-02-02 13:13:32 -0500, Jeffrey Stedfast wrote:
>>   * tell GMime to disable crl checks
>
> I'd be willing to add an API to disable CRL checks if there's a way I
> can pass that along to gpgme.

thanks!

>>   * tell GMime not to verify S/MIME signatures at all
>
> Willing to add an API for this as well (although I guess it's not
> necessary if an API to disable CRL checks is added?)

i would rather not disable signature verification if we can do it
without metadata leakage.

> Well, I suppose that, like S/MIME signature verification, it would also
> disable PGP key-server lookups?

ah, right, i should be clearer about the use cases.  I'm thinking right
now about the use of GMime for *reading* mail.  (Maybe we can talk about
composing mail separately?)

Is there any point during mail reading that you expect GMime to trigger
a PGP keyserver lookup?

> It might be best if there was a way to disable CRL checks on a per
> gpgme_ctx_t basis as opposed to globally, but I can have GMime use the
> global option until such an option exists (note: might be racey if you
> try and verify signatures on multiple threads).

gpgme_set_offline is actually per-gpgme_ctx_t:

   -- Function: void gpgme_set_offline (gpgme_ctx_t CTX, int YES)

Sorry that i omitted that from the shorthand in my earlier message.

But how would i use that with GMime?  As of GMime 3 i'm in the practice
of not not having to handle the GMimeCryptoCtx directly, because Gmime
does the Right Thing anyway :) -- i'd like to keep that nice behavior!

GMime should consider it as a new value for GMimeVerifyFlags?  But i
notice that g_mime_multipart_encrypted_decrypt () only takes a
GMimeDecryptFlags, and it probably affects this too.  I'll send a
separate message to gmime-devel about this.

> I'll wait for the GnuPG/GPGME devs to comment before making changes to
> GMime.

your message doesn't appear to have been let through to the gnupg-devel@
mailing list yet [0], so perhaps it's in moderation.

        --dkg

[0] https://lists.gnupg.org/pipermail/gnupg-devel/2018-February/

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

signature.asc (847 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [gmime-devel] avoiding metadata leaks when handling S/MIME-signed mail in GMime and other tools that use GnuPG

GnuPG - Dev mailing list
I've added code locally to set offline mode but reading the docs:

https://www.gnupg.org/documentation/manuals/gpgme/Offline-Mode.html

it suggests that setting offline mode only works for CMS and not OpenPGP? Can anyone from the GPGME team verify this? If so, I'll drop the flags that would indicate that this works in OpenPGP mode.

Jeff

On 2/2/18, 2:24 PM, "gmime-devel-list on behalf of Daniel Kahn Gillmor" <[hidden email] on behalf of [hidden email]> wrote:

    On Fri 2018-02-02 13:13:32 -0500, Jeffrey Stedfast wrote:
    >>   * tell GMime to disable crl checks
    >
    > I'd be willing to add an API to disable CRL checks if there's a way I
    > can pass that along to gpgme.
   
    thanks!
   
    >>   * tell GMime not to verify S/MIME signatures at all
    >
    > Willing to add an API for this as well (although I guess it's not
    > necessary if an API to disable CRL checks is added?)
   
    i would rather not disable signature verification if we can do it
    without metadata leakage.
   
    > Well, I suppose that, like S/MIME signature verification, it would also
    > disable PGP key-server lookups?
   
    ah, right, i should be clearer about the use cases.  I'm thinking right
    now about the use of GMime for *reading* mail.  (Maybe we can talk about
    composing mail separately?)
   
    Is there any point during mail reading that you expect GMime to trigger
    a PGP keyserver lookup?
   
    > It might be best if there was a way to disable CRL checks on a per
    > gpgme_ctx_t basis as opposed to globally, but I can have GMime use the
    > global option until such an option exists (note: might be racey if you
    > try and verify signatures on multiple threads).
   
    gpgme_set_offline is actually per-gpgme_ctx_t:
   
       -- Function: void gpgme_set_offline (gpgme_ctx_t CTX, int YES)
   
    Sorry that i omitted that from the shorthand in my earlier message.
   
    But how would i use that with GMime?  As of GMime 3 i'm in the practice
    of not not having to handle the GMimeCryptoCtx directly, because Gmime
    does the Right Thing anyway :) -- i'd like to keep that nice behavior!
   
    GMime should consider it as a new value for GMimeVerifyFlags?  But i
    notice that g_mime_multipart_encrypted_decrypt () only takes a
    GMimeDecryptFlags, and it probably affects this too.  I'll send a
    separate message to gmime-devel about this.
   
    > I'll wait for the GnuPG/GPGME devs to comment before making changes to
    > GMime.
   
    your message doesn't appear to have been let through to the gnupg-devel@
    mailing list yet [0], so perhaps it's in moderation.
   
            --dkg
   
    [0] https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.gnupg.org%2Fpipermail%2Fgnupg-devel%2F2018-February%2F&data=02%7C01%7Cjestedfa%40microsoft.com%7Ca93726fccf3341b635ba08d56a72a2c3%7Cee3303d7fb734b0c8589bcd847f1c277%7C1%7C0%7C636531962953290821&sdata=31FiENC95WdhP0le8lNFj%2BMG92pmesnANJic2TFnzLA%3D&reserved=0
   

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Reply | Threaded
Open this post in threaded view
|

Re: [gmime-devel] avoiding metadata leaks when handling S/MIME-signed mail in GMime and other tools that use GnuPG

Daniel Kahn Gillmor-7
On Sat 2018-02-03 18:48:26 +0000, Jeffrey Stedfast wrote:
> I've added code locally to set offline mode but reading the docs:
>
> https://www.gnupg.org/documentation/manuals/gpgme/Offline-Mode.html
>
> it suggests that setting offline mode only works for CMS and not
> OpenPGP? Can anyone from the GPGME team verify this? If so, I'll drop
> the flags that would indicate that this works in OpenPGP mode.

hm, it's not just "only CMS" -- it says:

    Offline mode only affects the keylist mode
    GPGME_KEYLIST_MODE_VALIDATE and is only relevant to the CMS crypto
    engine. Offline mode is ignored otherwise.

in which case, that might mean that it doesn't affect signature
verification at all. :(

GnuPG folks -- what is the best way for a user of GPGME to avoid
metadata leakage in this scenario as a default configuration?

         --dkg

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

signature.asc (847 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: avoiding metadata leaks when handling S/MIME-signed mail in GMime and other tools that use GnuPG

Bernhard Reiter-7
In reply to this post by Daniel Kahn Gillmor-7
Hello,

Am Freitag 02 Februar 2018 18:48:08 schrieb Daniel Kahn Gillmor:
> I recently learned that default handling of signed S/MIME mail with
> GnuPG causes an inherent metadata leak about the user's activity:
>
>     https://dev.gnupg.org/T3348#110132

from briefly reading over the issue I think that "inherent metadata leak"
is too broad a term to represent the security pros and cons well enough.

Just sending an email or a webpage will also inherently leak meta data
for someone listening on the line. So you'll certainly won't disable begin
able to send those as well.

> As a MUA developer, I'd like my MUA to simply handle as much crypto as
> it can on the user's behalf automatically, correctly and silently,
> without needing any special configuration or asking the user to make any
> tough tradeoffs that they might object to.

Users might also object to the higher exposure to revoked certificates
and a more surprising behaviour deviating from the CMS standards (which as far
as I know mandate checking the validity of certs).

It comes down to post some trust into the implementations and the certificate
authorities you chose to use. I think we'd do more for users if we educate
them about some of the more basic properties.

Best Regards,
Bernhard

--
www.intevation.de/~bernhard   +49 541 33 508 3-3
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

signature.asc (484 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [gmime-devel] avoiding metadata leaks when handling S/MIME-signed mail in GMime and other tools that use GnuPG

Werner Koch
In reply to this post by GnuPG - Dev mailing list
On Sat,  3 Feb 2018 19:48, [hidden email] said:

> it suggests that setting offline mode only works for CMS and not OpenPGP? Can anyone from the GPGME team verify this? If so, I'll drop the flags that would indicate that this works in OpenPGP mode.

This is correct.  The offline mode currently works only with gpgsm:

  The offline mode specifies if dirmngr should be used to do additional
  validation that might require connections to external services.
  (e.g. CRL / OCSP checks).
 
  Offline mode only affects the keylist mode
  @code{GPGME_KEYLIST_MODE_VALIDATE} and is only relevant to the CMS
  crypto engine. Offline mode is ignored otherwise.
 
  This option may be extended in the future to completely disable the
  use of dirmngr for any engine.

I think it is time to do this now: https://dev.gnupg.org/T3831


Salam-Shalom,

   Werner

--
#  Please read:  Daniel Ellsberg - The Doomsday Machine  #
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

attachment0 (233 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [gmime-devel] avoiding metadata leaks when handling S/MIME-signed mail in GMime and other tools that use GnuPG

Jeffrey Stedfast-3
In reply to this post by GnuPG - Dev mailing list
I kinda dropped the ball on this a while back but due to the recent
Efail news, I resurrected my patch and have now committed it:

https://github.com/jstedfast/gmime/commit/57d16f7ca9ff76e2c46c518db43b6822a2ea075a

There is now a GMIME_VERIFY_DISABLE_ONLINE_CERTIFICATE_CHECKS flag that
sets gpgsm into offline mode.

Question: Should this behavior be the default? I.e. should I invert the
logic for DISABLE_ONLINE_CERTIFICATE_CHECKS into
*ENABLE*_ONLINE_CERTIFICATE_CHECKS?

I'm wondering if perhaps that might be more prudent.

Unfortunately, I think that means it opens the client up to other
potential risks such as letting revoked certificates go undiscovered.

Comments? Suggestions?

Jeff

On 2/3/2018 1:48 PM, Jeffrey Stedfast wrote:

> I've added code locally to set offline mode but reading the docs:
>
> https://www.gnupg.org/documentation/manuals/gpgme/Offline-Mode.html
>
> it suggests that setting offline mode only works for CMS and not OpenPGP? Can anyone from the GPGME team verify this? If so, I'll drop the flags that would indicate that this works in OpenPGP mode.
>
> Jeff
>
> On 2/2/18, 2:24 PM, "gmime-devel-list on behalf of Daniel Kahn Gillmor" <[hidden email] on behalf of [hidden email]> wrote:
>
>      On Fri 2018-02-02 13:13:32 -0500, Jeffrey Stedfast wrote:
>      >>   * tell GMime to disable crl checks
>      >
>      > I'd be willing to add an API to disable CRL checks if there's a way I
>      > can pass that along to gpgme.
>      
>      thanks!
>      
>      >>   * tell GMime not to verify S/MIME signatures at all
>      >
>      > Willing to add an API for this as well (although I guess it's not
>      > necessary if an API to disable CRL checks is added?)
>      
>      i would rather not disable signature verification if we can do it
>      without metadata leakage.
>      
>      > Well, I suppose that, like S/MIME signature verification, it would also
>      > disable PGP key-server lookups?
>      
>      ah, right, i should be clearer about the use cases.  I'm thinking right
>      now about the use of GMime for *reading* mail.  (Maybe we can talk about
>      composing mail separately?)
>      
>      Is there any point during mail reading that you expect GMime to trigger
>      a PGP keyserver lookup?
>      
>      > It might be best if there was a way to disable CRL checks on a per
>      > gpgme_ctx_t basis as opposed to globally, but I can have GMime use the
>      > global option until such an option exists (note: might be racey if you
>      > try and verify signatures on multiple threads).
>      
>      gpgme_set_offline is actually per-gpgme_ctx_t:
>      
>         -- Function: void gpgme_set_offline (gpgme_ctx_t CTX, int YES)
>      
>      Sorry that i omitted that from the shorthand in my earlier message.
>      
>      But how would i use that with GMime?  As of GMime 3 i'm in the practice
>      of not not having to handle the GMimeCryptoCtx directly, because Gmime
>      does the Right Thing anyway :) -- i'd like to keep that nice behavior!
>      
>      GMime should consider it as a new value for GMimeVerifyFlags?  But i
>      notice that g_mime_multipart_encrypted_decrypt () only takes a
>      GMimeDecryptFlags, and it probably affects this too.  I'll send a
>      separate message to gmime-devel about this.
>      
>      > I'll wait for the GnuPG/GPGME devs to comment before making changes to
>      > GMime.
>      
>      your message doesn't appear to have been let through to the gnupg-devel@
>      mailing list yet [0], so perhaps it's in moderation.
>      
>              --dkg
>      
>      [0] https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.gnupg.org%2Fpipermail%2Fgnupg-devel%2F2018-February%2F&data=02%7C01%7Cjestedfa%40microsoft.com%7Ca93726fccf3341b635ba08d56a72a2c3%7Cee3303d7fb734b0c8589bcd847f1c277%7C1%7C0%7C636531962953290821&sdata=31FiENC95WdhP0le8lNFj%2BMG92pmesnANJic2TFnzLA%3D&reserved=0
>      
>


_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Reply | Threaded
Open this post in threaded view
|

Re: [gmime-devel] avoiding metadata leaks when handling S/MIME-signed mail in GMime and other tools that use GnuPG

Daniel Kahn Gillmor-7
On Sat 2018-05-19 14:42:54 -0400, Jeffrey Stedfast wrote:

> I kinda dropped the ball on this a while back but due to the recent
> Efail news, I resurrected my patch and have now committed it:
>
> https://github.com/jstedfast/gmime/commit/57d16f7ca9ff76e2c46c518db43b6822a2ea075a
>
> There is now a GMIME_VERIFY_DISABLE_ONLINE_CERTIFICATE_CHECKS flag that
> sets gpgsm into offline mode.
>
> Question: Should this behavior be the default? I.e. should I invert the
> logic for DISABLE_ONLINE_CERTIFICATE_CHECKS into
> *ENABLE*_ONLINE_CERTIFICATE_CHECKS?
>
> I'm wondering if perhaps that might be more prudent.
>
> Unfortunately, I think that means it opens the client up to other
> potential risks such as letting revoked certificates go undiscovered.
I lean toward the default being no metadata leakage.

I agree that there is a risk about revoked certificates going
undetected, but that's something that the certificate scheme needs to
deal with separately, i think, and it's not appropriate to deal with it
at message investigation time.

thanks for working on this, Jeff.

   --dkg

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

signature.asc (233 bytes) Download Attachment