GnuPG key management issues

RT Users
1

Hello all,

we are using the RT::Crypt::GnuPG module and have run into an issue that
I’m afraid we cannot solve.

Recently, some german mail providers, most notably GMX (one of the
biggest free webmail providers in Europe) have enabled end-to-end
encryption for their users. This is implemented using OpenPGP keys and a
browser plug-in (modified version of Mailvelope).

However, GMX does not publish the generated keys to a keyserver.
Instead, users can send a so-called “invitation to encrypted
communication” which is essentially an auto-generated mail that has the
public key attached in an .asc attachment. [I am told by some customers that this is the way some commercial mail servers/appliances seem to handle key management, too.]

This is where the problems start. With our current setup (and a local
keyring on the RT server), RT will try handling the .asc attachment as
encrypted data (which it isn’t), fail and not handle the rest of the
ticket. The requestor will receive a mail saying RT found invalid PGP
data in their request.

To remedy this (and add the key to RT’s keyring), we currently have to
manually extract the pubkey, scp it to the RT, add the key to the
keyring and then re-set permissions (since gpg seems to modify ownership
to the user who last modified a keyring file) to the web server. This is
clumsy, error-prone and a security issue (since ssh access to our RT box
is restricted with good reason).

Also, it’s unfortunately not possible to make GMX or our other customers
with similar behavior change their mail format - this is clearly out of
scope.

We are using RT 4.0.8. Is there any configuration setting that I might
have missed, or any other possibility to get RT to automatically import
keys that come into the system as a .asc attachment? I am aware of the
security implications of this (and, in fact, have set the trust settings
to “always”, as authentication of user requests is always performed
separately).

Best regards,

–ck

2

We are using RT 4.0.8. Is there any configuration setting that I might

I’m sorry, it’s actually RT 4.2.8.

Regards,

–ck

3

we are using the RT::Crypt::GnuPG module and have run into an issue that
I’m afraid we cannot solve.
[snip]
This is where the problems start. With our current setup (and a local
keyring on the RT server), RT will try handling the .asc attachment as
encrypted data (which it isn’t), fail and not handle the rest of the
ticket.

I believe the 4.2/skip-asc-keys branch[1] addresses this particular
issue, of interpreting .asc as encrypted data. I’m sure that BPS
would appreciate the feedback if it resolves the issue for you.

We are using RT 4.2.8. Is there any configuration setting that I might
have missed, or any other possibility to get RT to automatically import
keys that come into the system as a .asc attachment? I am aware of the
security implications of this (and, in fact, have set the trust settings
to “always”, as authentication of user requests is always performed
separately).

The security implications of such a flag almost certainly preclude its
inclusion in core RT – though you understand the security
implications, many sites might not, and might enable it regardless of
any warnings placed on it. Operating in such configurations is far
worse than operating without GPG at all.

If you wish to implement this yourself, there are a couple options for
where to implement the behavior. The first two of them will require
that the web user have write access to the keyring.

  1. Implement it as a mail plugin, run before RT::Crypt::GnuPG. This
    will allow it to import the key before the decryption happens.
    Mail plugins in 4.2 are cumbersome, but an ApplyBeforeDecode
    plugin that is in @MailPlugins before Auth::Crypt should work fine.

    I would suggest using RT::Extension::FutureMailgate[2] backport
    of the 4.4/mailgate-refactor branch[3] to make writing the mail
    plugin entirely more friendly, but I just checked, and it looks
    like that backport doesn’t include the Crypt changes from the
    branch[3], so running that may be unhelpful.

  2. Write a scrip to parse out the keys after the mail comes in.
    This means that if the original mail is signed by the key it
    includes, the key will be added after it has been examined, so it
    will be marked as unverified.

  3. Pre-process the keys in the mail gateway, or before. If the mail
    has a standard format, you can potentially do all of the work by
    having procmail or similar match the message and pipe it to a
    custom program that extracts and adds the key. This removes RT
    from the loop entirely.

If this is central to your workflow, you may wish to consider
contacting sales@bestpractical.com to see if they can help you
implement one of the above solutions.

  • Alex

[1] https://github.com/bestpractical/rt/compare/4.2-trunk...4.2/skip-asc-keys
[2] GitHub - bestpractical/rt-extension-futuremailgate
[3] https://github.com/bestpractical/rt/compare/master...4.4/gateway-refactor

4

Hi,

I believe the 4.2/skip-asc-keys branch[1] addresses this particular
issue, of interpreting .asc as encrypted data. I’m sure that BPS
would appreciate the feedback if it resolves the issue for you.

Thanks for the pointer! I think it does solve the painful part of the
issue, indeed. I manually patched our 4.2.8 installation and now the
.asc attachments still cause a warning in the log, but no other
undesired effects.

The security implications of such a flag almost certainly preclude its
inclusion in core RT – though you understand the security
implications, many sites might not, and might enable it regardless of
any warnings placed on it. Operating in such configurations is far
worse than operating without GPG at all.

I agree. I’d like to point out, though, that a veiled hint at the
“always trust” option is already in the doc for RT::Crypt::GnuPG. Quote:
"Encrypting to untrusted keys

Due to limitations of GnuPG, it’s impossible to encrypt to an untrusted
key, unless ‘always trust’ mode is enabled."

Maybe there should be a notice after that sentence to the effect of
“this is in most cases a very bad idea”.

If you wish to implement this yourself, there are a couple options for
where to implement the behavior. The first two of them will require
that the web user have write access to the keyring.

I’m not a Perl guy, so developing our own solution is not in scope at
the moment. In addition, I really don’t think it does solve the actual
issue, which is that GMX is spewing out potentially hundreds of
thousands of unverifiable OpenPGP keys. It would be FAR better if they
(semi-automatically) uploaded them to a keyserver and maybe added some
trust level via their own management keys. After all, the owners of
gmx.net can certify that a key belongs to randommember@gmx.net and
therefore authenticate that relation. Anyway, I’m sure since there
actually are a lot of very smart people working there, they will roll
out some of that eventually.

If this is central to your workflow, you may wish to consider
contacting sales@bestpractical.com to see if they can help you
implement one of the above solutions.

I might just do that, after asking my customer if he’ll pay for it.
First, however, I will try to educate them on the advantages of using
keyservers.

Thanks for your help, my biggest pain is solved! :slight_smile:

Best regards,

–ck