This is how you test totemomail
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.
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.
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.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.
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.
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.
Our experts will get in contact with you!
Our experts will get in contact with you!
Further articles available here