In my last week's blog post
, I covered the hurdles we face in meeting Secure by Default for email. Now let’s dive into how we can tackle them and improve email security for everyone.
There is still hope for secure by default in email communication. The Internet standards bodies are working on additional standards to address the weaknesses of StartTLS. The two most notable are Message Transfer Agent – Strict Transport Security (MTA-STS) and DNS-based Authentication of Named Entities (DANE)
MTA-STS allows an organization to publish policies, via a combination of DNS and HTTPS, that define whether sending mail servers can expect authenticated TLS support and direction on what to do if authenticated TLS session is not available, such as bouncing email as undeliverable. This enables the equivalent of a Mandatory TLS connection without manual configuration. To make it known to sending mail servers that an organization supports MTA-STS, the organization must publish an MTA-STS text record in their Domain Name System (DNS). Sending mail servers can check for the MTS-STS record in DNS and cache the TLS requirements from the defined URL for future connections. The one down-side of MTA-STS is that if the DNS record is not digitally signed using Domain Name System Security Extensions (DNSSEC), then the first connection is still vulnerable to the same DNS poisoning attack referenced in my previous post.
DANE for TLS
DANE for TLS allows an organization to publish their TLS certificate and authentication requirements for TLS in DNS. The ability to publish TLS certificate information in DNS makes it possible to do Mandatory TLS without the manual configuration – each organization need only worry about properly maintaining its own certificate information in DNS. Before issuing StartTLS, the sending mail server queries DNS for the DANE TLS record, and if it exists, the StartTLS becomes mandatory. The sending mail server can then use the information from DNS to authenticate the certificate provided during the TLS handshake. Publishing the TLS certificate in DNS eliminates the potential TLS down-grade attack associated with Opportunistic TLS by making certificate validation a requirement at the time the connection is requested.
The DANE standard has been around longer than MTA-STS and has additional benefits, such as also enabling the publishing of S/MIME certificates in DNS. One issue is that, even more than MTA-STS, the standard requires the use of DNSSEC. Without DNSSEC, DNS poisoning is possible, and the DANE published certificates cannot be fully trusted.
What should you do now?
For starters, you should enable StartTLS on your mail servers. Although there is the potential for MITM attacks, you will eliminate the potential for passive attacks. The MITM attacks are possible whether or not StartTLS is enabled and can only be prevented with an email encryption solution that encrypts the email before sending over the Internet.
You should also start the process of implementing DNSSEC, if you have not already. By starting the process now you will be ready when these new secure email standards become readily available across the Internet. DNSSEC can also protect your organization from many other types of attacks and should be part of every organization’s security best practices.
Finally, implement an email encryption solution that can automatically detect and encrypt sensitive email data before sending over the Internet. Not only does email encryption strengthen protection by adding it at the message level, a separate email encryption solution will be required to ensure the confidentiality of sensitive data until the day that all email communication is sent securely without the risk of falling back to clear text or MITM attacks.
How Zix can improve TLS for your organization?
provides the ability to automatically detect and encrypt sensitive data and is also the only solution that combines the benefits of Opportunistic TLS with the security of Mandatory TLS. ZixEncrypt’s policy-based TLS allows sensitive emails to be encrypted using full certificate authentication to ensure the TLS connection is not vulnerable to MITM attacks. If an authenticated TLS connection cannot be established, the email is still encrypted using a secure web portal. ZixEncrypt also automatically does Opportunistic TLS on every email, even if it was already encrypted based on a policy. With ZixEncrypt, you get the strongest TLS without the need to manually manage every TLS connection.