Nowadays, most users browsing the World Wide Web would never think of sending sensitive information over a non-encrypted connection; users have been trained to tell an encrypted HTTPS connection from a cleartext HTTP one, looking for locks and other signs prominently displayed by their browser.
The same users, however, do not adopt the same care when sending email. The opportunistic encryption paradigm of the STARTTLS mechanism makes it very hard for email client applications to tell the user whether their message will be sent over an encrypted connection or not. Users trust their email provider to take care of security, though they are usually very concerned, and often outraged, when they discover that their provider does not secure their emails properly, and that all their messages are subject to email interception.
What makes it difficult to encrypt all email traffic, however, it is that both servers involved in an email transmission must support secure encryption for it to happen. Even if you implement the latest security mechanisms, you will not be able to use them if the other provider does not support them.
This is what is already happening at the national level in some countries, such as with the Email made in Germany project. The TES project promotes a global effort in this direction.
To start, you should ensure that your email server has opportunistic encryption turned on, both for sending and for receving, and will use STARTTLS and encrypt connections whenever possible. Even a self-signed certificate is enough for STARTTLS, and many server applications will create it for you when installing them; if you like, you may still use a certification authority (even a free one such as Letsencrypt) to deploy on your server a TLS certificate that includes a third-party validation of your identity, but it does not make any difference for STARTTLS, and the use of DANE will authenticate your server even with a self-signed certificate.
Just by this, however, you do not significantly increase your email transport security, because opportunistic encryption will still send your email in clear if the other party does not support STARTTLS. To increase security, you would have to refuse sending messages in clear, and rather bounce messages if an encrypted connection cannot be established; but this would possibly reject a significant number of legitimate messages.
As more and more providers adopt encryption, a time will come when everyone will be able to turn off unencrypted communication and the few people who didn’t activate STARTTLS yet will have to do so or be cut off the Internet. For the time being, however, this is not recommended.
However, there are two cases in which you can – and should – safely disallow unencrypted communication. The first one is for mail submission and mail retrieval by the final users; client applications can be updated much more easily than servers, and all common clients have been supporting STARTTLS for a long time. So you should require the use of STARTTLS for mail submission and mail retrieval, or else refuse the connection.
Also, you should prevent passwords from being sent in clear, and to do so you should require authentication for all mail submission, and only offer authentication after the TLS connection has been established for both submission and retrieval.
The second case is when you are sure that the destination server supports TLS encryption: in that case, unless configuration errors have been made somewhere, any request for an unencrypted connection will imply an interception attempt and should cause the immediate interruption of the communication. DANE provides you with a mechanism to learn about the destination server’s encryption support.
Anyway, forcing the use of TLS over a connection is not enough to make it securely encrypted. As you examine the key features of the TLS protocol, you discover that TLS-encrypted connections can still be insecure if you use old versions of the protocol, insecure cipher suites and algorithms, or short keys. Actually, according to recent studies, almost half of the global encrypted email traffic is in fact insecure!
The TES technical standards specify in detail the acceptable configurations and parameters. However, a brief summary of secure configurations for TLS negotiation on your servers is the following:
- Use TLS 1.2 as a default, and accept TLS 1.1 as a fallback, but do not accept the use of TLS 1.0, SSL 3 or SSL 2.
- Do not accept the use of insecure cipher suites, including RC4, DES/3DES and MD5 (a full list is in the TES standards).
- Only use key agreement algorithms that provide forward secrecy (DHE and ECDHE).
- Only use keys at least 2048-bit long, possibly 4096.
Also, this NIST document provides more detailed guidelines on secure TLS configuration.
However, by implementing strictly and immediately all the above requirements you will reject even more legitimate messages, as many servers that accept opportunistic encryption do not support the most recent TLS configurations. So you may want to adopt those requirements in full only for destinations that certainly support up-to-date TLS encryption, and rather use a relaxed version (for example, still allowing TLS 1.0, but not SSL) in all other cases.
