This discussion has been locked.

You can no longer post new replies to this discussion. If you have a question you can start a new discussion

S/MIME and OpenPGP - risks and questions

DouglasFoster over 6 years ago

I am considering a rollout of email encryption, and trying to grasp the hidden risks to consider.

General

For some of the reasons below, it seems necessary to enable the option "Quarantine unscannable and encrypted content" on the Malware tab. Can someone confirm whether this is enforced on both inbound and outbound traffic, or inbound traffic only?
After making the above change, I may want to specify both the external users who are allowed to send encrypted messages and the internal users who are allowed to receive encrypted messages. The documentation for this is pretty fuzzy. I am guessing that Exempt from "AntiSpam" checking will do this, while exempting from "Email Encryption" will perform an unrelated function of ensuring that an outgoing message is never encrypted by UTM. Can anyone confirm this? I am looking for a way to disable only the quarantining of encrypted content, but that does not seem to be available.
It appears that UTM signing, verifying, encrypting, or decrypting at UTM will be documented with a comment block added to the front of the Subject line. So all of my later questions about disposition really come down to "the recipient gets the message and does what he wants based on the tag". Of course, adding a tag disrupts the ability to do DKIM checks downstream.
The UTM strategy of "encrypt whenever possible" might be a problem for the recipient, depending on how often his email client requires him to enter his private key password as he reads his mail. I don't know how to judge this without testing lots of email clients.
UTM just updated the algorithms for S/MIME to comply with GDPR. What algorithms does UTM support for OpenPGP, and will they need an update to be GDPR-compliant?
How do I assess whether my encryption technology (S/MIME or OpenPGP) will work with another organization's implementation of the same technology, other than to give it a try and wait for failures?

PGP / OpenPGP

It appears that a PGP public key can be retrieved from a keyserver using only an email address. Spammers have collected billions of email addresses. If I publish my public key to a keyserver, the spammers can retrieve my public key and send me an encrypted message in hopes of penetrating my spam filters. Of course, if I do not publish to a keyserver, my desired correspondents may have frustrations when trying to obtain my public key. (If I use UTM to decrypt messages, my spam risk goes down but I no longer have data encrypted at rest or encrypted to the final recipient, which makes the result similar to TLS transmit encryption.)
The spam threat is increased if I accept encrypted email that is not signed, since signing the message increases the visibility of the spam source. Does UTM have a way for me to specify the disposition of emails that are encrypted but not signed?
Suppose I use a keyserver to obtain the public keys of others. How do I know that all of the public keys that I see for Example.com were actually published by Example.com? I don't want a spammer to create a bogus key for someone@example.com and use the bogus key to create a bogus signature to facilitate social engineering of my users.
What is the UTM policy for email with unverifiable signatures? Is this something that I can configure?
What enforcement does UTM perform to see if the PGP signing email address matches the Message Header From Address or the SMTP Authenticated-As Address, or both? SMTP Authenticated-As is difficult (but not impossible) to match with a signature because it often has the username encoded using BATV, SRS, for VERP techniques. If there is no enforcement, doesn't that weaken the whole concept? Where is this documented or configured?
How do I configure whether or not signatures are added to non-encrypted messages? I am swayed by those who say you should not attach a signature on messages to recipients who cannot interpret it, but this does not seem to be configurable in UTM, and the needs for S/MIME are probably different than for OpenPGP.

S/MIME

Public key exposure does not seem to be a concern, because the lookup is not based on the email address alone. Nonetheless, I still want to reject email that is encrypted without being signed, and quarantine mail that has an unverifiable signature. Document does not seem to explain
The normal way to initiate encryption is to send a signed-but-not-encrypted email in each direction, but I would still like to avoid nuisance signatures for messages that are going to organizations that cannot utilize them.
There is the related problem that UTM allows a user to have both OpenPGP and S/MIME keys. If automatic signing is enabled, how does UTM know which signature to send to which organization when doing sign-but-not-encrypt? I guess it will attach both signatures until the recipient replies and provides a public key that UTM can use to pick the recipients signature technology. Can anyone confirm or correct that guess? Dual signature attachments will be a real nuisance for recipient organizations that understand neither.
The question of synchronization between incoming signatures and from address is also a concern with S/MIME. This may be addressed in the standard, but it would be desirable to have UTM documentation on what is done. I have also not seen it addressed in my reading about client-based S/MIME implementations.
Some documentation talks about triple-wrap, where the message is signed before and after encryption. Does UTM do this on outbound mail? Does it understand this on incoming mail?

Evolving convictions:

Do not use PGP keyservers.
Even if all signing and encrypting is performed at the email client, or if no outbound encryption is performed at all, it is probably desirable to have UTM verify signatures.

This thread was automatically locked due to age.

Parents

DouglasFoster over 6 years ago

Just ran into a complication. I started to deploy encryption between two divisions, one that is behind UTM and one that is external to UTM. The planned UTM implementation is for outbound encryption to occur at the client, and inbound decryption to occur at UTM.

I was hoping to use UTM to generate keys for both user groups. Happily, it will generate user keys for a user unrelated to any incoming mail domain. Unhappily, it does not allow export of private keys, for security reasons. I cannot argue with the security concern, but it means that I have to buy commercial certificates or build an in-house key or certificate generation process.
Cancel
Vote Up 0 Vote Down

Cancel

Reply

DouglasFoster over 6 years ago

Just ran into a complication. I started to deploy encryption between two divisions, one that is behind UTM and one that is external to UTM. The planned UTM implementation is for outbound encryption to occur at the client, and inbound decryption to occur at UTM.

I was hoping to use UTM to generate keys for both user groups. Happily, it will generate user keys for a user unrelated to any incoming mail domain. Unhappily, it does not allow export of private keys, for security reasons. I cannot argue with the security concern, but it means that I have to buy commercial certificates or build an in-house key or certificate generation process.
Cancel
Vote Up 0 Vote Down

Cancel

Children

DouglasFoster over 6 years ago in reply to DouglasFoster

I have constructed a grid of encryption configuration options and the related configuration tasks. It helped me to organize my thoughts and plan my strategy. I include Password Protected Files and

My related assumptions and conclusions

I assume that signing and encryption occur together. Similarly, signature verification and decryption occur together.
Encrypting every outbound message to a user seems to be too much of a burden on the recipient, given an assumption that many messages will not require encryption, and that every decryption operation requires inconvenience to the recipient because they must activate their encryption key, with a password, a special program, or both. This makes me reluctant to use encryption at UTM, except for outbound SPX. This decision requires me to bypass Antispam checking on outbound mail for authorized users, but I assume that my network is generally clean and is therefore risk I can accept.
Allowing inbound decryption requires a significant weakening of defenses. I must either disable the global setting to “Quarantine encrypted and unscannable messages” or disable “Antispam Checking” for either the allowed users or the allowed senders. Granting any exception to a sender, even a trusted one, seems unacceptable because sender identity is so difficult to prove decisively, and I do not want to risk granting an exception to a fraudulent user. Disabling “Antispam Checking” for all message coming to a user seems equally unacceptable. So disabling Quarantine of encrypted messages for all users seems the least objectionable. However, this option also means that encrypted messages bypass all spam checking and that gives me heartburn.
Given the above, my most appealing scenario is to encrypt at the client and decrypt at the UTM. This allows me to quarantine encrypted material that cannot be decrypted at UTM, and allows me to keep antispam defenses in place for all users.
If I must accept password-protected files for any users, the Quarantine Encrypted/Unscannable option must be off. This includes SPX files from other Sophos clients, since SPX generates on a password-protected PDF. One can hope that if an encrypted file is hostile, the user will not know how to decrypt it, or will choose not to do so.
PGP seems difficult to deploy and administer because of the difficulty of collecting and distributing keys. Implementing PGP in my suggested configuration is even more difficult, because it requires collecting the necessary keys at both the client and all of the user devices. Keeping user devices and UTM will be challenging, especially if keyservers are not used because of the concerns in my previous post.
Ultimately, the decision between S/MIME and PGP will be driven by the encryption method that communication partners are willing to deploy. If given the choice, S/MIME seems preferable to PGP.

I hope somebody finds this useful. It took awhile to get my head around the complexity of these options. I would love to hear from someone who already has this working.

Table 1: Outbound Encryption, Options at Client device

Function	Setup	Encrypt Trigger	UTM Must Allow	Receiving Firewall Setup	Receiving User Setup
Password-Protected File	Sender must generate and deliver password	User sets password before attaching to mail message	Quarantine Encrypted off, or Scan outgoing off, or "Antispam checking" exception for sender or recipient	Must allow password-protected files for user	Receiver must obtain and track passwords
S/MIME at Client	Issue certificates to users. Deploy user certificate to client devices. Capture recipient certificates from signed messages.	User activates with S/MIME features of email client	Quarantine Encrypted off, or Scan outgoing off, or "Antispam checking" exception for sender or recipient. Also to avoid double-encryption, need "Signature Off" and "Encrypt Off" for sender, or "Email Encryption" exception for sender.	Must allow encrypted messages	Obtain personal certificate, capture sender certificate from a signed message.
PGP at Client	Generate and deploy user keys. Optionally deploy public keys to a keyserver. Install personal private key, acquire receiver public keys or use keyserver, on all client devices.	User activates with PGP plug-in for email client.	Quarantine Encrypted off, or Scan outgoing off, or "Antispam checking" exception for sender or recipient. Also to avoid double-encryption, need "Signature Off" and "Encrypt Off" for sender, or "Email Encryption" exception for sender.	Must allow encrypted messages	Obtain personal private key and sender public keys. Optionally use keyserver.

Table 2: Outbound Encryption, Options at UTM

Function	Setup	Encrypt Trigger	UTM Must Allow	Receiving Firewall Setup	Receving User Setup
SPX	Enable SPX, configure DLP rules, deploy Outlook plug-in, configure SPX template	UTM encrypts after sender activates with Outlook Plug-In or triggers a DLP rule	Not Applicable	Must allow password-protected files for user	User must obtain and track passwords
S/MIME at UTM	Issue certificates to users. Enable "Automatic S/MIME certificate extraction". Define "Internal User" to UTM Encryption.	UTM activates when message is received and receiver certificate is available.	Default or User configured for "Signature On" and "Encrypt On"	Must allow encrypted messages	Obtain personal certificate, capture sender certificate from a signed message.
PGP at UTM	Generate user keys, store at UTM. Acquire recipient public keys. Optionally exchange public keys with a keyserver. Define "Internal User" to UTM Encryption	UTM activates when message is received and receiver public key is available.	Default or User configured for "Signature On" and "Encrypt On"	Must allow encrypted messages	Obtain personal private key and sender public keys. Optionally use keyserver.

Table 3: Inbound Decryption, Options at Client

Function	Setup	Decrypt Trigger	UTM Must Allow	Sending Firewall Setup	Sending User Setup
Password-Protected File (includes incoming SPX)	Receiver must obtain and track passwords	Decrypted when user reads the message and enters file password.	Quarantine Encrypted off, or "Antispam checking" exception for sender or recipient	Must allow password-protected files for sender	Sender must generate and deliver passwords
S/MIME at Client	Issue certificates to users. Deploy user certificate to client devices. Capture sender certificates from signed messages.	Decrypted when user reads the message and enters certificate password.	Quarantine Encrypted off, or "Antispam checking" exception for sender or recipient	Must allow encrypted messages for sender	Obtain personal certificate, capture recipient certificate from a signed message.
PGP at Client	Generate and deploy user keys. Optionally deploy public keys to a keyserver. Install personal private key, acquire receiver public keys or use keyserver.	Decrypted when user reads the message and enters private key password.	Quarantine Encrypted off, or "Antispam checking" exception for sender or recipient	Must allow encrypted messages for sender	Obtain personal private key and recipient public keys. Optionally use keyserver.

Table 4: Inbound Decryption, Options at UTM

Function	Setup	Decrypt Trigger	UTM Must Allow	Sending Firewall Setup	Sending User Setup
S/MIME at UTM	Issue/generate certificates for users. Enable "Automatic S/MIME certificate extraction". Capture sender certificates from signed messages.	Automatically converted to cleartext when recevied at UTM	Default or User configured for "Verify Signature On" and "Decrypt On"	Must allow encrypted messages for sender	Obtain personal certificate, capture recipient certificate from a signed message.
PGP at UTM	Generate user keys, store at UTM. Optionally deploy public keys to a keyserver. Define "Internal User" to UTM Encryption	Automatically converted to cleartext when recevied at UTM	Default or User configured for "Verify Signature On" and "Decrypt On"	Must allow encrypted messages for sender	Obtain personal private key and recipient public keys. Optionally use keyserver.

DouglasFoster over 6 years ago in reply to DouglasFoster
Discussed some of these issues at my ISC2 chapter meeting this week. Since it was not a group of UTM users, the conversation focused on the risks of allowing encrypted messages to the end user. We concluded that incoming encrypted messages really are a problem. We also concluded that for key-based technologies like S/MIME and PGP, you need to attempt to control who acquires the public key:

Because the encrypted payload has been allowed to bypass the perimeter defenses, you need really good endpoint protection. Unfortunately, really good endpoint protection is really hard to construct.

Once the public key is released to anyone for any purpose, the key owner cannot prevent its distribution outside of his control, although he could retire and replace it. Therefore, we need to worry about unwanted senders of encrypted messages, just as we worry about unwanted senders of clear-text messages. To my thinking, this means a whitelist of allowed sender-recipient pairs, a feature which UTM does not offer. But authorized senders are difficult to define because of the problems with misrepresentation in email.

Signing every outbound message with S/MIME or PGP seems like a terrible idea, because this releases your public key to people who do not need it. Wikipedia says that really smart people use one keypair for signing, and a different keypair for encryption. This would allow you to sign all outgoing emails (to prove authenticity) without worrying about the signature public key ever being used for unwanted incoming encryption.

If a PGP or S/MIME message is "triple-wrapped", the receiving spam filter could potentially use the outer signature to test for allowed-sender status.

Overall, this conversation ratified my perceptions that:

Quarantining of encrypted/unscannable content is critically important for network security.

PGP and S/MIME traffic must be decrypted at the UTM, not at the client device, if it is used at all.
Cancel
Vote Up 0 Vote Down

Cancel