CipherMail Email Encryption - bloghttps://www.ciphermail.com/2023-12-22T00:00:00+01:00SMTP Smuggling - Spoofing E-Mails Worldwide2023-12-22T00:00:00+01:002023-12-22T00:00:00+01:00Martijn Brinkerstag:www.ciphermail.com,2023-12-22:/blog/smtp-smuggling-spoofing-emails-worldwide.html<p>SEC Consult Vulnerability Lab, Timo Longin discovered a novel exploitation technique for SMTP</p><p>SEC Consult Vulnerability Lab, Timo Longin discovered a novel exploitation technique for SMTP
(Simple Mail Transfer Protocol).</p>
<p>Basically, the vulnerability exploits differences between smtp servers on how they handle non-standard end-of-message sequences.</p>
<p>To exploit the vulnerability, two mail servers with different handling of non-standard end-of-message sequences are required. </p>
<p>The exploit makes it possible to smuggle/send spoofed e-mails.</p>
<p>CipherMail Gateway/Webmail uses Postfix for delivering email. </p>
<p>If Postfix receives an email from a vulnerable SMTP server, Postfix will deliver the "smuggled" email as a separate email. </p>
<p>To stop Postfix from accepting the "smuggled" email, unauthorized pipelining should be disabled. </p>
<p>To disable unauthorized pipelining, the following parameter should be added to Postfix main config:</p>
<p><code></p>
<div class="highlight"><pre><span></span><code>smtpd_data_restrictions = reject_unauth_pipelining
</code></pre></div>
<p></code></p>
<p>This can be added from the CipherMail GUI (<strong>Admin -> MTA -> Config -> MTA config file</strong>)</p>
<p>Then add the above <code>smtpd_data_restrictions</code> line to the end of the config file and apply.</p>
<p>Alternatively, the Postfix main configuration file can be directly edited from the command line:</p>
<p><code></p>
<div class="highlight"><pre><span></span><code>$ sudo vim /etc/postfix/main.cf
$ sudo systemctl restart postfix.service
</code></pre></div>
<p></code></p>
<p>For more information see:</p>
<p><a href="https://sec-consult.com/blog/detail/smtp-smuggling-spoofing-e-mails-worldwide/">https://sec-consult.com/blog/detail/smtp-smuggling-spoofing-e-mails-worldwide/</a></p>
<p><a href="https://www.postfix.org/smtp-smuggling.html">https://www.postfix.org/smtp-smuggling.html</a></p>
<p>Please <a href="https://www.ciphermail.com/contact.html">contact us</a> if you need more information.</p>CipherMail Gateway and Webmail Messenger are not impacted by the Log4j vulnerabilities2021-12-12T00:00:00+01:002021-12-12T00:00:00+01:00Martijn Brinkerstag:www.ciphermail.com,2021-12-12:/blog/ciphermail-gateway-and-webmail-messenger-are-not-vulnerable-to-cve-2021-44228.html<p>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 …</p><p>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.</p>
<p>This means that CipherMail Gateway and Webmail Messenger are <strong>not</strong> 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.</p>
<p>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 <em>does</em> 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.</p>
<p>If you have any questions or suggestions regarding the security of our
products, please don't hesitate to <a href="https://www.ciphermail.com/contact.html">contact
us</a>.</p>
<p>UPDATE December 15, 2021: added some background information and intentions on
updating Log4j and other library versions that are no longer supported.</p>HTML email is now fully supported by the PDF encryption module2021-12-03T00:00:00+01:002021-12-03T00:00:00+01:00Martijn Brinkerstag:www.ciphermail.com,2021-12-03:/blog/html-email-is-now-supported-by-pdf-encryption-module.html<p>The PDF encryption module of PDF messenger now fully supports HTML email and embedded images.</p><p>Before discussing the new HTML feature, first a quick overview of the PDF encryption functionality provided by CipherMail gateway and Webmail Messenger. </p>
<h2>PDF messenger</h2>
<p>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.</p>
<p>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:</p>
<ol>
<li>Use a pre-defined static password.</li>
<li>Randomly generate a password. The password will be sent back to the sender of the message.</li>
<li>Randomly generate a password. The password will then be sent by SMS Text to the recipient.</li>
<li>Generate a one time password (OTP).</li>
<li>Sender specified password.</li>
</ol>
<p><center><img alt="PDF messenger" src="https://www.ciphermail.com/images/ciphermail-pdf.svg"></center></p>
<h2>PDF messenger features</h2>
<ul>
<li>The PDF is encrypted with AES128.</li>
<li>Attachments are embedded within the encrypted PDF.</li>
<li>The original email can be attached (as .eml file)</li>
<li>The recipient can reply by clicking the reply button.</li>
<li>Full Unicode support.</li>
<li>HTML email is supported, including embedded images [new]</li>
<li>PDF template is fully configurable [new]</li>
</ul>
<h2>HTML support</h2>
<p>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.</p>
<p>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.</p>
<p>The template for the encrypted PDF is fully configurable. This allows you to match the corporate identity.</p>
<p>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.</p>
<p>Clearly, the HTML supported version is much more appealing.</p>
<h3>Encrypted PDF with HTML support</h3>
<p><center><img alt="Encrypted PDF professional edition" src="https://www.ciphermail.com/images/encrypted-pdf-professional-edition.png"><em> Encrypted PDF with HTML support </em></center></p>
<h3>Encrypted PDF with only text support</h3>
<p><center><img alt="Encrypted PDF community edition" src="https://www.ciphermail.com/images/encrypted-pdf-community-edition.png"><em> Encrypted PDF with only text support </em></center></p>
<h2>Future developments</h2>
<p>We are working hard on providing additional features for PDF messenger. Some of the features we are currently working on:</p>
<ul>
<li>Digital signing of the encrypted PDF.</li>
<li>Provide an Android and IOS app which can be used to generate the password for the PDF (using the HOTP algorithm).</li>
</ul>Automating CipherMail deployments2021-07-05T00:00:00+02:002021-07-05T00:00:00+02:00Imre Jonktag:www.ciphermail.com,2021-07-05:/blog/automating-ciphermail-deployments.html<p>No need to manually edit configuration files and copying them to all cluster nodes anymore, CipherMail is now automated!</p><p><center><img alt="Ansible logo" src="https://www.ciphermail.com/images/ansible-logo.svg"></center></p>
<p>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 (<a href="/blog/eating-our-own-dog-food.html">like we do ourselves</a>) 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.</p>
<p>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 <a href="/news/ciphermail-is-now-a-red-hat-isv-partner.html">Red Hat Independent Software Vendor</a>! 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. <a href="https://docs.debops.org/en/master/">DebOps</a> 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.</p>
<p>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.</p>
<p>If you are interested in a demonstration of the new automation system, don't hesitate to <a href="https://www.ciphermail.com/contact.html">contact us</a>.</p>Eating our own dog food2020-07-16T00:00:00+02:002020-07-16T00:00:00+02:00Imre Jonktag:www.ciphermail.com,2020-07-16:/blog/eating-our-own-dog-food.html<p>This article will give some insight in how we use our products ourselves as a way of quality control and testimonial advertising.</p><p>This posting is a bit different from the usual articles on our blog. Instead of telling you how <em>you</em> 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.</p>
<p>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:</p>
<p><img alt="Schematic drawing of email infrastructure, showing CipherMail gateway in a hairpin configuration" src="https://www.ciphermail.com/images/ciphermail-gateway-with-content-scanner-redirect.svg"></p>
<p>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 <em>and</em> 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.</p>
<p>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.</p>
<p>Our new clustered email system is spread out over three data centers and consists of these components:</p>
<ul>
<li>Virtual machines (KVM, libvirt, Azure)</li>
<li>Four LDAP servers (OpenLDAP)</li>
<li>Two mail servers (Postfix, Dovecot, Rspamd)</li>
<li>Two HTTP load balancers (NGINX)</li>
<li>Three CipherMail Gateway nodes</li>
<li>Three CipherMail Webmail nodes</li>
</ul>
<p> </p>
<p>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.</p>
<p>We turned to the <a href="https://docs.debops.org/en/master/">DebOps project</a> 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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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 <a href="https://wiki.dovecot.org/Replication">little configuration</a> required and works without any maintenance once it’s set up. CipherMail Webmail also uses dsync to sync mail between cluster nodes.</p>
<p>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.</p>
<p>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.</p>
<p>Putting everything together, our current email infrastructure looks like this:</p>
<p><img alt="Schematic drawing of an email infrastructure consisting of a two-node mail cluster, two load balancers, a three-node CipherMail Gateway cluster and a three-node CipherMail Webmail cluster" src="https://www.ciphermail.com/images/email-infra.png"></p>
<p>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.</p>
<p>If this article made you interested in our products, please <a href="https://www.ciphermail.com/contact.html">contact Us</a> for a demo, or try out the open source <a href="https://www.ciphermail.com/downloads.html">community edition</a> yourself. You can find more information about DebOps and its awesome community on the <a href="https://docs.debops.org/en/master/">documentation website</a> as well as the <a href="https://github.com/debops/debops">GitHub repository</a>. The custom roles that we wrote and are currently integrating with DebOps can be found on <a href="https://gitlab.com/ciphermail?filter=debops">our GitLab page</a>.</p>CipherMail CVE-2020-12713 & CVE-2020-127142020-05-28T00:00:00+02:002020-05-28T00:00:00+02:00Martijn Brinkerstag:www.ciphermail.com,2020-05-28:/blog/ciphermail-cve-2020-12713_2020-12714.html<p>Background info on CVE-2020-12713 & CVE-2020-12714</p><p>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.</p>
<h2>Postfix main configuration</h2>
<p>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 (<em>main.cf</em>). 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. </p>
<p>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. </p>
<p>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.</p>
<h3>The fix</h3>
<p>Fixing this vulnerability requires that we only allow settings to be changed that are considered safe. We added a variable, <em>allowed_settings</em>, 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.</p>
<p>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 <em>postfix-main-config.sh</em> script file, mitigating the issue. See below for instructions on how to apply this patch.</p>
<h2>Backup and restore</h2>
<p>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. </p>
<p>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.</p>
<h3>Additional non-SQL commands</h3>
<p>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). </p>
<p>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.</p>
<h3>Signing the backup file?</h3>
<p>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. </p>
<h3>Parsing the SQL dump?</h3>
<p>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.</p>
<h3>Additional backup files</h3>
<p>Besides the SQL file, the backup file contains additional configuration files. One such configuration file is the Postfix main configuration file (<em>main.cf</em>). 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. </p>
<p>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.</p>
<h3>The fix</h3>
<p>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.</p>
<h4><strong>Additional system password</strong></h4>
<p>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.</p>
<h4><strong>Disable restore from the GUI</strong></h4>
<p>The second solution is to completely remove the restore functionality from the web interface. Restores can now only be done from the command line.</p>
<p>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.</p>
<h3>Check your backups</h3>
<p>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.</p>
<h2>Weak Diffie-Hellman keys</h2>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<h2>Should I update or patch?</h2>
<p>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.</p>
<h2>Patch instructions for older releases</h2>
<h3>For the CipherMail Gateway:</h3>
<ol>
<li>
Download <a href="https://www.ciphermail.com/downloads/patches/ciphermail-gateway-cve-2020-12713.patch.run">ciphermail-gateway-cve-2020-12713.patch.run</a>
</li>
<li>
Make the file executable
<code>
<div class="highlight"><pre><span></span><code>$ chmod +x ciphermail-gateway-cve-2020-12713.patch.run
</code></pre></div>
</code>
</li>
<li>
Execute the patch
<code>
<div class="highlight"><pre><span></span><code>$ sudo ./ciphermail-gateway-cve-2020-12713.patch.run
</code></pre></div>
</code>
</li>
<li>
Select which vulnerability should be fixed.
</li>
<li>
Select "yes" for each issue you want to fix.
</li>
</ol>
<h3>For CipherMail Webmail Messenger:</h3>
<ol>
<li>
Download <a href="https://www.ciphermail.com/downloads/patches/ciphermail-webmail-cve-2020-12713.patch.run">ciphermail-webmail-cve-2020-12713.patch.run</a>
</li>
<li>
Make the file executable
<code>
<div class="highlight"><pre><span></span><code>$ chmod +x ciphermail-webmail-cve-2020-12713.patch.run
</code></pre></div>
</code>
</li>
<li>
Execute the patch
<code>
<div class="highlight"><pre><span></span><code>$ sudo ./ciphermail-webmail-cve-2020-12713.patch.run
</code></pre></div>
</code>
</li>
<li>
Select which vulnerability should be fixed.
</li>
<li>
Select "yes" for each issue you want to fix.
</li>
</ol>
<h2>Patch instructions for older releases</h2>
<p>Customers with a support contract who have additional questions or need help fixing the issue, either by running the patch or updating, please <a href="https://www.ciphermail.com/contact.html">Contact Us</a>.</p>
<h2>Credits</h2>
<p>We like to thank Pablo A. Zurro from Core Security for reporting the privilege escalation issues ethically.</p>EFAIL: detection and prevention2018-05-19T00:00:00+02:002018-05-19T00:00:00+02:00Martijn Brinkerstag:www.ciphermail.com,2018-05-19:/blog/efail-detection-and-prevention.html<p>EFAIL: detection and prevention</p><p><img alt="EFAIL" src="https://www.ciphermail.com/images/efail-logo.png" width="75px"></p>
<p>In <a href="efail-which-is-vulnerable-pgp-smime-or-your-mail-client.html">EFAIL: which is vulnerable? PGP, S/MIME or your mail client?</a>, we discussed the <a href="https://efail.de">EFAIL</a> "Generic exfiltration"
attack on S/MIME and suggested how such an attack may be detected.</p>
<p>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.</p>
<p>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.</p>
<blockquote>
<p>... 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.</p>
</blockquote>
<p>In <a href="fail-how-to-detect-you-are-being-attacked.html">EFAIL: how to detect you are being attacked?</a>, we discussed a
possible option to detect that an S/MIME encrypted email was modified.</p>
<p>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 <a href="fail-how-to-detect-you-are-being-attacked.html">EFAIL: how to detect you are being attacked?</a>)</p>
<p>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.</p>
<p><img alt="Check for valid 7bit chars" src="https://www.ciphermail.com/images/check-for-invalid-7bits-chars.png"></p>
<p>The following two advanced S/MIME options were added: <em>Check for invalid 7bit chars</em> and <em>Abort decrypt on invalid 7bit chars</em>.
If <em>Check for invalid 7bit chars</em> 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:</p>
<p><code></p>
<div class="highlight"><pre><span></span><code>WARN Illegal characters detected in decrypted message
</code></pre></div>
<p></code></p>
<p>If <em>Abort decrypt on invalid 7bit chars</em> 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:</p>
<p><code></p>
<div class="highlight"><pre><span></span><code>WARN Decryption aborted. Illegal characters detected in decrypted message
</code></pre></div>
<p></code></p>
<p>The options <em>Check for invalid 7bit chars</em> and <em>Abort decrypt on invalid 7bit chars</em> 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.</p>EFAIL: how to detect you are being attacked?2018-05-15T00:00:00+02:002018-05-15T00:00:00+02:00Martijn Brinkerstag:www.ciphermail.com,2018-05-15:/blog/efail-how-to-detect-you-are-being-attacked.html<p>EFAIL: how to detect you are being attacked?</p><p><img alt="EFAIL" src="https://www.ciphermail.com/images/efail-logo.png" width="75px"></p>
<p>In <a href="efail-which-is-vulnerable-pgp-smime-or-your-mail-client.html">EFAIL: which is vulnerable? PGP, S/MIME or your mail client?</a>, we discussed some implications of the newly found <a href="https://efail.de">EFAIL</a> 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. </p>
<p>The EFAIL paper describes two types of attack. The <em>Direct exfiltration</em> attack and the <em>Generic exfiltration</em> attack. </p>
<p>Messages decrypted by the CipherMail gateway are not vulnerable to the <em>Direct exfiltration</em> attack even if you use a mail client which is vulnerable to the <em>Direct exfiltration</em> attack because CipherMail will always generate messages having correct MIME parts after decryption. PGP messages decrypted by CipherMail are also not vulnerable to the <em>Generic exfiltration</em> 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 <a href="efail-which-is-vulnerable-pgp-smime-or-your-mail-client.html">EFAIL: which is vulnerable? PGP, S/MIME or your mail client?</a> for more details)</p>
<h2>S/MIME</h2>
<p>S/MIME however is vulnerable to the <em>Generic exfiltration</em> attack. With the <em>Generic exfiltration</em> 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. </p>
<h2>Generic exfiltration</h2>
<p>We have further analyzed EFAIL and have been able to modify an S/MIME message using the described <em>Generic exfiltration</em> technique. </p>
<p>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. </p>
<p><img alt="EFAIL" src="https://www.ciphermail.com/images/efail-random-data.png"></p>
<p>The bogus data however, can also be used to detect that an EFAIL attack has been executed. S/MIME specification (<a href="https://tools.ietf.org/html/rfc5751#section-3.1.3">RFC 5751</a>) requires that an S/MIME message should only contain 7-bits characters:</p>
<blockquote>
<p>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.</p>
</blockquote>
<p>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.</p>
<p>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.</p>
<h2>Automatic detection</h2>
<p>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. </p>
<h2>Update</h2>
<p>This functionality has now been implemented in the CipherMail Email Encryption Gateway. For more information see
<a href="efail-detection-and-prevention.html">EFAIL: detection and prevention</a></p>EFAIL: which is vulnerable? PGP, S/MIME or your mail client?2018-05-14T00:00:00+02:002018-05-14T00:00:00+02:00Martijn Brinkerstag:www.ciphermail.com,2018-05-14:/blog/efail-which-is-vulnerable-pgp-smime-or-your-mail-client.html<p>EFAIL: which is vulnerable? PGP, S/MIME or your mail client?</p><p><img alt="EFAIL" src="https://www.ciphermail.com/images/efail-logo.png" width="75px"></p>
<p>EFAIL is a recent attack on PGP en S/MIME email encryption (<a href="https://efail.de">EFAIL</a>).</p>
<p>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.</p>
<p>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.</p>
<h2>Two forms of attack</h2>
<p>EFAIL described two forms of attack: <em>Direct exfiltration</em> and <em>Generic exfiltration</em>.</p>
<h2>Direct exfiltration</h4></h2>
<p>With <em>Direct exfiltration</em>, the email client is tricked into embedding the decrypted message into the URL of an image URL.</p>
<p>Take for example the following email:</p>
<p><code></p>
<div class="highlight"><pre><span></span><code><span class="n">MIME</span><span class="o">-</span><span class="nl">Version</span><span class="p">:</span><span class="w"> </span><span class="mf">1.0</span><span class="w"></span>
<span class="n">Content</span><span class="o">-</span><span class="nl">Type</span><span class="p">:</span><span class="w"> </span><span class="n">multipart</span><span class="o">/</span><span class="n">mixed</span><span class="p">;</span><span class="w"> </span><span class="n">boundary</span><span class="o">=</span><span class="ss">"------------BOUNDARY"</span><span class="w"></span>
<span class="o">--------------</span><span class="n">BOUNDARY</span><span class="w"></span>
<span class="n">Content</span><span class="o">-</span><span class="nl">Type</span><span class="p">:</span><span class="w"> </span><span class="nc">text</span><span class="o">/</span><span class="n">html</span><span class="p">;</span><span class="w"></span>
<span class="o"><</span><span class="n">img</span><span class="w"> </span><span class="n">src</span><span class="o">=</span><span class="err">"</span><span class="nl">http</span><span class="p">:</span><span class="o">//</span><span class="n">www</span><span class="p">.</span><span class="n">example</span><span class="p">.</span><span class="n">com</span><span class="o">/</span><span class="w"></span>
<span class="o">--------------</span><span class="n">BOUNDARY</span><span class="w"></span>
<span class="n">Content</span><span class="o">-</span><span class="nl">Type</span><span class="p">:</span><span class="w"> </span><span class="nc">text</span><span class="o">/</span><span class="n">plain</span><span class="p">;</span><span class="w"></span>
<span class="o">-----</span><span class="k">BEGIN</span><span class="w"> </span><span class="n">PGP</span><span class="w"> </span><span class="n">MESSAGE</span><span class="o">-----</span><span class="w"></span>
<span class="nl">Charset</span><span class="p">:</span><span class="w"> </span><span class="n">ISO</span><span class="o">-</span><span class="mi">8859</span><span class="o">-</span><span class="mi">1</span><span class="w"></span>
<span class="nl">Version</span><span class="p">:</span><span class="w"> </span><span class="n">GnuPG</span><span class="w"> </span><span class="n">v1</span><span class="mf">.4.11</span><span class="w"> </span><span class="p">(</span><span class="n">GNU</span><span class="o">/</span><span class="n">Linux</span><span class="p">)</span><span class="w"></span>
<span class="n">hQEMA4qqZxiq3q9</span><span class="o">/</span><span class="n">AQf</span><span class="o">/</span><span class="n">bNb91v6gBd2UE9FF4PcyoCBEA95GQyom</span><span class="o">/</span><span class="n">xrRB9dl44xp</span><span class="w"></span>
<span class="o">[</span><span class="n">SNIP</span><span class="o">]</span><span class="w"></span>
<span class="n">nHDNjX1d8QF9V4Q22MCImLA</span><span class="o">=</span><span class="w"></span>
<span class="o">=</span><span class="n">i3mI</span><span class="w"></span>
<span class="o">-----</span><span class="k">END</span><span class="w"> </span><span class="n">PGP</span><span class="w"> </span><span class="n">MESSAGE</span><span class="o">-----</span><span class="w"></span>
<span class="o">--------------</span><span class="n">BOUNDARY</span><span class="w"></span>
<span class="n">Content</span><span class="o">-</span><span class="nl">Type</span><span class="p">:</span><span class="w"> </span><span class="nc">text</span><span class="o">/</span><span class="n">html</span><span class="p">;</span><span class="w"></span>
<span class="n">Content</span><span class="o">-</span><span class="n">Transfer</span><span class="o">-</span><span class="nl">Encoding</span><span class="p">:</span><span class="w"> </span><span class="mi">7</span><span class="nc">bit</span><span class="w"></span>
<span class="o">></span><span class="w"></span>
<span class="c1">--------------BOUNDARY--</span>
</code></pre></div>
<p></code></p>
<p>An email client is vulnerable to the <em>Direct exfiltration</em> attack if the above email, afer decryption, ends up as follows:</p>
<p><code></p>
<div class="highlight"><pre><span></span><code><span class="nt">MIME-Version</span><span class="o">:</span><span class="w"> </span><span class="nt">1</span><span class="p">.</span><span class="nc">0</span><span class="w"></span>
<span class="nt">Content-Type</span><span class="o">:</span><span class="w"> </span><span class="nt">multipart</span><span class="o">/</span><span class="nt">mixed</span><span class="o">;</span><span class="w"></span>
<span class="w"> </span><span class="nt">boundary</span><span class="o">=</span><span class="s2">"------------BOUNDARY"</span><span class="w"></span>
<span class="nt">This</span><span class="w"> </span><span class="nt">is</span><span class="w"> </span><span class="nt">a</span><span class="w"> </span><span class="nt">multi-part</span><span class="w"> </span><span class="nt">message</span><span class="w"> </span><span class="nt">in</span><span class="w"> </span><span class="nt">MIME</span><span class="w"> </span><span class="nt">format</span><span class="o">.</span><span class="w"></span>
<span class="nt">--------------BOUNDARY</span><span class="w"></span>
<span class="nt">Content-Type</span><span class="o">:</span><span class="w"> </span><span class="nt">text</span><span class="o">/</span><span class="nt">html</span><span class="o">;</span><span class="w"></span>
<span class="nt">Content-Transfer-Encoding</span><span class="o">:</span><span class="w"> </span><span class="nt">7bit</span><span class="w"></span>
<span class="o"><</span><span class="nt">img</span><span class="w"> </span><span class="nt">src</span><span class="o">=</span><span class="err">"</span><span class="nt">http</span><span class="o">://</span><span class="nt">www</span><span class="p">.</span><span class="nc">example</span><span class="p">.</span><span class="nc">com</span><span class="o">/</span><span class="w"></span>
<span class="nt">Decrypted</span><span class="w"> </span><span class="nt">text</span><span class="w"></span>
<span class="o">></span><span class="w"></span>
</code></pre></div>
<p></code></p>
<p>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.</p>
<p>The CipherMail email encryption gateway is not vulnerable to the <em>Direct exfiltration</em> attack. CipherMail will create a valid email with correct mail parts. CipherMail will create the following email from the above <em>Direct exfiltration</em> attack:</p>
<p><code></p>
<div class="highlight"><pre><span></span><code><span class="nt">MIME-Version</span><span class="o">:</span><span class="w"> </span><span class="nt">1</span><span class="p">.</span><span class="nc">0</span><span class="w"></span>
<span class="nt">Content-Type</span><span class="o">:</span><span class="w"> </span><span class="nt">multipart</span><span class="o">/</span><span class="nt">mixed</span><span class="o">;</span><span class="w"></span>
<span class="w"> </span><span class="nt">boundary</span><span class="o">=</span><span class="s2">"------------BOUNDARY"</span><span class="w"></span>
<span class="nt">This</span><span class="w"> </span><span class="nt">is</span><span class="w"> </span><span class="nt">a</span><span class="w"> </span><span class="nt">multi-part</span><span class="w"> </span><span class="nt">message</span><span class="w"> </span><span class="nt">in</span><span class="w"> </span><span class="nt">MIME</span><span class="w"> </span><span class="nt">format</span><span class="o">.</span><span class="w"></span>
<span class="nt">--------------BOUNDARY</span><span class="w"></span>
<span class="nt">Content-Type</span><span class="o">:</span><span class="w"> </span><span class="nt">text</span><span class="o">/</span><span class="nt">html</span><span class="o">;</span><span class="w"></span>
<span class="nt">Content-Transfer-Encoding</span><span class="o">:</span><span class="w"> </span><span class="nt">7bit</span><span class="w"></span>
<span class="o"><</span><span class="nt">img</span><span class="w"> </span><span class="nt">src</span><span class="o">=</span><span class="err">"</span><span class="nt">http</span><span class="o">://</span><span class="nt">www</span><span class="p">.</span><span class="nc">example</span><span class="p">.</span><span class="nc">com</span><span class="o">/</span><span class="w"></span>
<span class="nt">--------------BOUNDARY</span><span class="w"></span>
<span class="nt">Content-Type</span><span class="o">:</span><span class="w"> </span><span class="nt">text</span><span class="o">/</span><span class="nt">plain</span><span class="o">;</span><span class="w"> </span><span class="nt">charset</span><span class="o">=</span><span class="nt">ISO-8859-1</span><span class="w"></span>
<span class="nt">Content-Transfer-Encoding</span><span class="o">:</span><span class="w"> </span><span class="nt">7bit</span><span class="w"></span>
<span class="nt">Decrypted</span><span class="w"> </span><span class="nt">text</span><span class="w"></span>
<span class="nt">--------------BOUNDARY</span><span class="w"></span>
<span class="nt">Content-Type</span><span class="o">:</span><span class="w"> </span><span class="nt">text</span><span class="o">/</span><span class="nt">html</span><span class="o">;</span><span class="w"></span>
<span class="nt">Content-Transfer-Encoding</span><span class="o">:</span><span class="w"> </span><span class="nt">7bit</span><span class="w"></span>
<span class="o">></span><span class="w"></span>
<span class="nt">--------------BOUNDARY--</span><span class="w"></span>
</code></pre></div>
<p></code></p>
<p>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.</p>
<h2>Generic exfiltration</h2>
<p>The <em>Generic exfiltration</em> attack is more difficult to exploit. With the <em>Generic exfiltration</em> 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. </p>
<p>In general, the <em>Generic exfiltration</em> 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.</p>
<h2>CipherMail for Android</h2>
<p>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.</p>
<h2>Mitigation</h2>
<p>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).</p>
<h2>Bottom line</h2>
<p>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 <em>Generic exfiltration</em> attack). The <em>Direct exfiltration</em> attack however, is more an email client issue and should therefore be fixed by the email clients.</p>
<p>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. </p>
<p>Messages decrypted by the CipherMail gateway are not vulnerable to the <em>Direct exfiltration</em> attack even if you use an email client which is vulnerable to the <em>Direct exfiltration</em> attack because CipherMail will always generate messages with correct MIME parts after decryption. PGP messages decrypted by CipherMail are also not vulnerable to the <em>Generic exfiltration</em> 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.</p>
<p>S/MIME Messages decrypted by CipherMail might be be vulnerable to the <em>Generic exfiltration</em> 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.</p>
<p>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.</p>
<h2>Update</h2>
<p>For more information on how to detect if you are attacked with EFAIL see <a href="efail-how-to-detect-you-are-being-attacked.html">EFAIL: how to detect you are being attacked?</a></p>Will DANE for SMTP solve all of your GDPR problems?2018-05-09T00:00:00+02:002018-05-09T00:00:00+02:00Martijn Brinkerstag:www.ciphermail.com,2018-05-09:/blog/will-dane-for-smtp-solve-your-gdpr-problems.html<p>The short answer: probably not. The long answer: keep reading.</p><h2>Will DANE for SMTP solve all of your GDPR problems?</h2>
<p>The short answer: probably not. The long answer: keep reading.</p>
<h2>What is DANE?</h2>
<p>According to
<a href="https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities">Wikipedia</a>:</p>
<blockquote>
<p>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)</p>
</blockquote>
<p>In less technical terms, DANE is a protocol which allows you to securely
associate a domain name with an X.509 certificate.</p>
<p>To support DANE, the following key ingredients are required:</p>
<ol>
<li>The client (for example a web browser or SMTP client) and server
must support DNSSEC.</li>
<li>Client and server must support the DANE protocol.</li>
<li>Server certificate must be stored in DNS and the DNS record must be
signed.</li>
</ol>
<p>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.</p>
<p>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.</p>
<h2>Example</h2>
<p>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:</p>
<div class="highlight"><pre><span></span><code>overheid.nl. 300 IN MX 20 mx01-koop.solvinity.com.
overheid.nl. 300 IN MX 20 mx02-koop.solvinity.com.
</code></pre></div>
<p>Because the domain <strong>overheid.nl</strong> does not match the domain
<strong>solvinity.com</strong> it's impossible to know for certain that the servers
<strong>mx01-koop.solvinity.com</strong> and <strong>mx02-koop.solvinity.com</strong> 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.</p>
<p>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.</p>
<h2>Issues with DANE</h2>
<p>The problem with DANE is that DNSSEC is required. DNSSEC is however
still not widely deployed. Big players like Microsoft (Office 365)<sup id="fnref:1"><a class="footnote-ref" href="#fn:1">1</a></sup>
and Gmail<sup id="fnref:2"><a class="footnote-ref" href="#fn:2">2</a></sup> at the moment do not support DNSSEC.</p>
<p>DANE requires that DNSSEC is supported by sender and recipient. Setting
up DNSSEC is not easy and error prone.</p>
<p>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.</p>
<p>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.</p>
<h2>Combine DANE with message encryption</h2>
<p>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.</p>
<hr>
<div class="footnote">
<hr>
<ol>
<li id="fn:1">
<p><a href="https://web.archive.org/web/20201112021649/https://office365.uservoice.com/forums/289138-office-365-security-compliance/suggestions/32360299-dnssec-support-in-office-365">DNSSEC support in Office 365</a> <a class="footnote-backref" href="#fnref:1" title="Jump back to footnote 1 in the text">↩</a></p>
</li>
<li id="fn:2">
<p><a href="https://dane.sys4.de/smtp/gmail.com">SMTP DNSSEC check</a> <a class="footnote-backref" href="#fnref:2" title="Jump back to footnote 2 in the text">↩</a></p>
</li>
</ol>
</div>Encrypted email and archiving requirements2017-01-31T00:00:00+01:002017-01-31T00:00:00+01:00Martijn Brinkerstag:www.ciphermail.com,2017-01-31:/blog/encrypted-email-and-archiving.html<p>Desktop email encryption might be conflicting with the requirement to archive email in a readable and searchable form. Placing an email encryption gateway before the archiving system might help to fulfill both requirements.</p><p>Even though we believe that email encryption at the gateway level is the
easiest way to encrypt your email<sup id="fnref:1"><a class="footnote-ref" href="#fn:1">1</a></sup>, 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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p><img alt="Drawing of email archiving setup with CipherMail Gateway" src="https://www.ciphermail.com/images/encrypted-email-and-archiving.jpg"></p>
<p>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<sup id="fnref:2"><a class="footnote-ref" href="#fn:2">2</a></sup>. Because the decryption gateway is
able to decrypt all email, access to the gateway should only be allowed
to certain key personnel.</p>
<p>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.</p>
<hr>
<div class="footnote">
<hr>
<ol>
<li id="fn:1">
<p><a href="https://www.ciphermail.com/news/what-does-it-take-for-johnny-to-start-encrypting-his-email.html">What does it take for Johnny to start encrypting his email?</a> <a class="footnote-backref" href="#fnref:1" title="Jump back to footnote 1 in the text">↩</a></p>
</li>
<li id="fn:2">
<p><a href="https://www.ciphermail.com/news/using-an-hsm-to-protect-your-encryption-and-signing-keys.html">Using an HSM to protect your encryption and signing keys</a> <a class="footnote-backref" href="#fnref:2" title="Jump back to footnote 2 in the text">↩</a></p>
</li>
</ol>
</div>What does it take for Johnny to start encrypting his email?2016-05-30T00:00:00+02:002016-05-30T00:00:00+02:00Martijn Brinkerstag:www.ciphermail.com,2016-05-30:/blog/what-does-it-take-for-johnny-to-start-encrypting-his-email.html<p>Why are most emails not encrypted? This might be because most email encryption products are too difficult to use. We propose that email encryption should be done at the gateway level.</p><h2>What does it take for Johnny to start encrypting his email?</h2>
<h2>Email is here to stay</h2>
<p>Despite the growing popularity of applications like WhatsApp, email is still considered to be the most important
communication tool for online workers <sup id="fnref:1"><a class="footnote-ref" href="#fn:1">1</a></sup> and is likely to grow in importance
over the next five years<sup id="fnref:2"><a class="footnote-ref" href="#fn:2">2</a></sup>.
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" <sup id="fnref:3"><a class="footnote-ref" href="#fn:3">3</a></sup>.
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".</p>
<h2>Rules and regulations</h2>
<p>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.</p>
<h2>The role of auditors</h2>
<p>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.</p>
<h2>Why is email encryption not used?</h2>
<p>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:</p>
<ul>
<li>Individual users are not motivated to encrypt their email.</li></li>
<li>Email encryption is too complex.</li></li>
</ul>
<p>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.</p>
<h2>How to make email encryption easier?</h2>
<p>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.</p>
<h2>Is Transport Layer Security (TLS) the solution?</h2>
<p>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.</p>
<h2>Use open standards</h2>
<p>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.</p>
<hr>
<div class="footnote">
<hr>
<ol>
<li id="fn:1">
<p><a href="https://www.pewinternet.org/2014/12/30/technologys-impact-on-workers/">Pew Research 2014</a> <a class="footnote-backref" href="#fnref:1" title="Jump back to footnote 1 in the text">↩</a></p>
</li>
<li id="fn:2">
<p><a href="https://www.reuters.com/article/us-usa-work-emails-idUSKCN0QV1I620150826">Reuters 2015</a> <a class="footnote-backref" href="#fnref:2" title="Jump back to footnote 2 in the text">↩</a></p>
</li>
<li id="fn:3">
<p><a href="https://www.fbi.gov/investigate/counterintelligence#Economic-Espionage">FBI Economic Espionage</a> <a class="footnote-backref" href="#fnref:3" title="Jump back to footnote 3 in the text">↩</a></p>
</li>
</ol>
</div>Using an HSM to protect your encryption and signing keys2016-05-23T00:00:00+02:002016-05-23T00:00:00+02:00Martijn Brinkerstag:www.ciphermail.com,2016-05-23:/blog/using-an-hsm-to-protect-your-encryption-and-signing-keys.html<p>A Hardware Security Module (HSM) can be used to securely store your private keys on a tamper-proof device. This is especially important when using qualified certificates.</p><p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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
(<a href="https://www.primekey.se">EJBCA</a>) 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.</p>
<p>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 <a href="http://www.thales-esecurity.com">Thales
nCipher</a>,
<a href="https://hsm.utimaco.com">Utimaco</a> and
<a href="http://www.safenet-inc.com/products/data-protection/hardware-security-modules-hsms">Safenet</a>
HSMs.</p>Why leaking email addresses is a data breach2016-05-15T00:00:00+02:002016-05-15T00:00:00+02:00Martijn Brinkerstag:www.ciphermail.com,2016-05-15:/blog/why-leaking-email-addresses-is-a-data-breach.html<p>Why leaking email addresses is a data breach and what can be done to prevent the common cc vs bcc mistake.</p><p>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. </p>
<p>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. </p>
<p>For example in 2015, an HIV clinic sent a news letter to 780 recipients
(<a href="https://www.theguardian.com/technology/2015/sep/02/london-clinic-accidentally-reveals-hiv-status-of-780-patients">Inquiry launched after HIV clinic reveals hundreds of patients' identities</a>)
Instead of using the bcc field, the sender used the cc field thereby revealing the identities of people having HIV.</p>
<p>There are plenty of other similar incidents which are considered to be a data breach:</p>
<ul>
<li><a href="http://www.nzherald.co.nz/politics/news/article.cfm?c_id=280&objectid=10874338" rel="nofollow">Another government agency apologises for privacy breach</a></li>
<li><a href="http://www.theregister.co.uk/2016/01/14/ftc_leaks_privacy_conf_attendee_info/" rel="nofollow">FTC apologizes for leaking attendee details to privacy conference</a></li>
<li><a href="http://www.thefirearmblog.com/blog/2016/01/15/breaking-the-batfe-leaked-the-emails-of-e-form-users/" rel="nofollow">The BATFE Leaked The Emails of 1,400 E-form Users</a></li>
</ul>
<p>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?</p>
<p>Instead of handling the cc problem client side (for example using an Outlook plugin), a system wide content scanner can
be used instead. </p>
<p>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.</p>
<p>See <a href="https://www.ciphermail.com/dlp-example-patterns.html">example DLP patterns</a> for some DLP patterns including a
pattern which quarantines the message if more than 20 email addresses are detected.</p>
<p>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.</p>Encrypted email, spam and the German law2016-05-10T00:00:00+02:002016-05-10T00:00:00+02:00Martijn Brinkerstag:www.ciphermail.com,2016-05-10:/blog/encrypted-email-spam-and-the-german-law.html<p>How to scan incoming encrypted email for viruses and spam and still be compliant with German law.</p><p>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. </p>
<p><img alt="CipherMail gateway after content scanner " src="https://www.ciphermail.com/images/ciphermail-gateway-with-content-scanner.svg"></p>
<p>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). </p>
<p>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. </p>
<p>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 <a href="https://en.wikipedia.org/wiki/Backscatter_%28email%29">backscatter</a>).</p>
<p>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. </p>
<p>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. </p>
<p>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<sup id="fnref:1"><a class="footnote-ref" href="#fn:1">1</a></sup>.</p>
<p>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.</p>
<p>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). </p>
<p>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.</p>
<p>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.</p>
<p><img alt="CipherMail gateway next to content scanner" src="https://www.ciphermail.com/images/ciphermail-gateway-with-content-scanner-redirect.svg"></p>
<p>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.</p>
<p>The Milter service will be available in the next release of CipherMail Enterprise.</p>
<div class="footnote">
<hr>
<ol>
<li id="fn:1">
<p><a href="http://www.heise.de/ct/artikel/Strafbares-Filtern-289128.html">Juristische Fallstricke für Antispam-Software</a><br>
<a href="http://www.searchsecurity.de/lernprogramm/Datenschutz-Rechtskonforme-Spam-Filterung">Datenschutz: Rechtskonforme Spam-Filterung</a><br>
<a href="https://sourceforge.net/p/amavis/mailman/message/21197243/">Amavis in pre-queue mode</a> <a class="footnote-backref" href="#fnref:1" title="Jump back to footnote 1 in the text">↩</a></p>
</li>
</ol>
</div>Waarom Jan zijn e-mail niet versleutelt?2014-11-13T00:00:00+01:002014-11-13T00:00:00+01:00Martijn Brinkerstag:www.ciphermail.com,2014-11-13:/blog/waarom-jan-zijn-e-mail-niet-versleutelt.html<p>(in Dutch) Waarom wordt e-mailversleuteling niet vaker toegepast? Hoe je ervoor kunt zorgen dat er vaker wordt versleuteld.</p><h2>We mailen er lekker op los!</h2>
<p>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.</p>
<h2>Hoe zit dat met veiligheidsnormen en de rol van de auditor?</h2>
<p>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.</p>
<h2>Is jouw e-mail geld waard?</h2>
<p>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.</p>
<h2>Iedereen veilige e-mail gebruiken en opgelost...</h2>
<p>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:</p>
<ol>
<li>Individuele eindgebruikers zoals Jan zijn niet gemotiveerd genoeg om
e-mail te versleutelen</li>
<li>Het is daarnaast allemaal te complex voor de eindgebruikers.</li>
</ol>
<p>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.</p>
<h2>Hoe kan het beter?</h2>
<p>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.</p>
<h2>Transport Layer Security de oplossing?</h2>
<p>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.</p>
<h2>De standaard is S/MIME en OpenPGP</h2>
<p>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.</p>
<p>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.</p>
<p>Dit artikel
<a href="https://www.cqure.nl/kennisplatform/waarom-jan-zijn-e-mail-niet-versleutelt/">verscheen</a>
eerder op het Cqure Kennisplatform.</p>Encrypted email in the cloud2014-06-06T00:00:00+02:002014-06-06T00:00:00+02:00Martijn Brinkerstag:www.ciphermail.com,2014-06-06:/blog/encrypted-email-in-the-cloud.html<p>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.</p><p>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. </p>
<p>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).</p>
<p>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).</p>
<p>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.</p>
<p>Using the <a href="https://www.mailvelope.com/">Mailvelope</a> 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.</p>
<p>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).</p>
<h3>Prerequisite</h3>
<p>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.</p>
<h3>Setup</h3>
<p>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:</p>
<p><img alt="encrypted email in the cloud" src="https://www.ciphermail.com/images/encrypted-email-in-the-cloud.jpg"></p>
<p>The following part will briefly explain the required steps on how to setup the above configuration.</p>
<ol>
<li>Install a CipherMail gateway.</li>
<li>Forward all email to Gmail.</li>
<li>Install Mailvelope.</li>
<li>Create a PGP secret key in Mailvelope (or import and existing key).</li>
<li>Import the PGP public key into the gateway.</li>
<li>Configure the gateway.</li>
</ol>
<h3>Install a CipherMail gateway</h3>
<p>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.</p>
<h3>Forward all email to Gmail</h3>
<p>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).</p>
<h3>Install Mailvelope</h3>
<p><a href="https://www.mailvelope.com/">Mailvelope</a> 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.</p>
<h3>Create a PGP secret key in Mailvelope (or import and existing key)</h3>
<p>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 <a href="https://www.mailvelope.com/help">Mailvelope help</a>
for instructions on how to generate or import a key. For every recipient a PGP secret key should be created.</p>
<h3>Import the PGP public key into the gateway</h3>
<p>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.</p>
<h3>Configure the gateway</h3>
<p>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.</p>
<h2>Reading encrypted email</h2>
<p>All email forwarded to Gmail will now be encrypted as can be seen from the inbox.<br>
When an email is opened, Mailvelope is activated. The user needs to enter the secret key password to read the encrypted email. </p>
<p><img alt="encrypted email in the cloud inbox" src="https://www.ciphermail.com/images/encrypted-email-in-the-cloud-inbox.png">
<img alt="encrypted email in the cloud message" src="https://www.ciphermail.com/images/encrypted-email-in-the-cloud-message.png"></p>
<h2>Discussion</h2>
<p>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.</p>
<h3>Searching</h3>
<p>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. </p>
<h3>Attachments</h3>
<p>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. </p>
<h3>HTML email</h3>
<p>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. </p>
<h3>Sending email</h3>
<p>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.</p>