Privacy and data security when communicating with our colleagues and partners is a recurring topic. It recently came to the forefront of public awareness again with WhatsApp’s changes to its privacy policies, but it remains an issue for businesses too. In particular, email is still one of the most common ways to communicate and it is not encrypted by default and the ways to deal with email encryption tend to be clunky and user-un-friendly.

Whether that means having to track down every possible recipient of an encrypted email and getting their certificate or PGP key, whether it is just having to add them as a contact in Outlook based on a signed email of theirs – and not the email that you are trying to write – or whether it is the hassle of setting up and managing a PGP key, especially if the Thunderbird extension you have been using for years suddenly stops working: Email encryption is not easy for users to handle, even if the organization they work for buys their S/MIME certificate for them. Then also there is the issue that truly end-to-end encrypted emails might conflict with internal policies or even laws that a company must follow. That is where products like totemomail come in.

Managed Email Encryption and More

What totemomail offers is taking the complexity of managing email encryption and putting it in a central place. There, it can be managed by dedicated administrators while the regular users just write emails and automatically benefit from having their emails encrypted.

Of course, that is an oversimplification. The totemomail product offers a lot of features apart from classic email encryption. You can set up shared encrypted mailboxes, processing rules that scan emails for malware or archive a copy, use different types of encryption, add spam warnings to messages, anything you might need.

Unsurprisingly, being this rich in features means there is a lot to configure and that the ruleset used can get very complex. The configuration file for totemomail is several tens of thousands of lines of XML long and while a lot of it is basically self-explanatory, it is not exactly easy to master. This is where an audit can help out.

How to secure it?

To start with, it is important to ensure that there are no logical mistakes in the routing of emails. Of course, the obvious mistakes get found within minutes, as emails fail to be sent or received. But with the complexity of totemomail routing it is possible to build more subtle mistakes that only trigger under certain circumstances. The ruleset might check for two markers to decide that an email to some external partner must be encrypted in a specific way but due to a typo, if only one marker is present both the regular encryption and the special case end up bypassed. An outside person going through the routing and asking questions about all the decisions can help uncover such mistakes.

But the trickier part is the configuration, which is where mistakes are easier to make. With the help of some Python scripting, the XML configuration can be cut down a bit to exclude inactive settings as well as ones that are not security-relevant, to make it more manageable.

Once that is done, one can find settings with insecure defaults or old values that were missed during upgrades to newer versions. For example security.pwd.hash.algorithm determines the hash algorithm used for user accounts and defaults to MD5 until recent versions. Unfortunately, the strongest choice currently available is SHA-512, which is not meant to be used as a password hash. More appropriate algorithms like scrypt have been promised for upcoming releases, though.

There are other settings too, which have less obvious and generally less direct risks. security.ssl.enabledCiphers by default allows all ciphers for TLS connections that the JRE provides – including insecure ones like SSL_NULL_WITH_NULL_NULL. Of course, totemomail uses more secure ciphers by default, but disabling them at the Java level is still recommended to decrease the available attack surface.

Then there are the classic security-relevant settings, like password lengths for users and administrators and whether to enable 2FA for them. By default, totemomail requires only a six-character password with no 2FA for its administrators, which has to be considered too short today. However, that is not to say that totemomail does not have sensible defaults at all. Its email security settings, for example are generally set sensibly, as are most of the protections for its web interfaces, like CSRF-tokens.

There are also less obvious settings like security.encryption.rsa.useOAEP and security.encryption.rsa.usePSS both of which serve to increase the security of RSA-based cipher suites and should be enabled if RSA is in use. Similarly, the policy audit log can be signed and should be signed with a secure algorithm, although for this, the default of SHA256withRSA is appropriate.

Attacking the Web Interface

As an auditor and penetration tester, the configuration is not the only thing to review, although it can give hints on what to focus on. There are multiple web-based interfaces to totemomail and a full audit should review these too. Fortunately, in the case of totemomail, these interfaces are well-secured. They provide only as much functionality as needed, in the case of the external mail interface, reducing the available attack surface and what is present did not present exploitable vulnerabilities.

This left the poor minimum password requirements as the biggest vulnerability for the web-based interfaces, relying on administrators and users to secure their accounts appropriately. Combined with the brute-force protections, even this vulnerability is not a major threat.

Conclusion

totemomail is a powerful and very useful tool, as are its competitors. However, it has some flaws and outdated assumptions still built in. While the web front end is reasonably well-secured, the application benefits from regularly checking the entire configuration and ensuring that its settings are set to the strongest values they can be. It is easy to miss a setting during an upgrade and to leave something at a default value that is not or no longer secure. Like any complex software, its complexity breeds risks.

About the Author

Mark Zeman has a Master of Science in Engineering with focus on Information and Communication Technologies at the FHNW. He was able to transform his passion of information security to his focus since 2017. During his bachelor studies he worked for an email security company. (ORCID 0000-0003-0085-2097)

Links

• https://www.totemo.com/en/products/email-encryption