Simple Mail Transfer Protocol (SMTP) is the protocol used for sending email over the Internet. Created in 1982, long before selling personal information on the dark web became big business, it was not designed to provide confidentiality of data. To help close the security gap, the StartTLS service extension was defined in 2002 to secure SMTP communication by using Transport Layer Security (TLS). StartTLS allows a sending mail server to negotiate a secure connection with the receiving mail server and create an encrypted tunnel for the email communication over the Internet.
StartTLS is often referred to as “Opportunistic TLS,” because the mail server will attempt to get a TLS connection, but if it is not available, the email is still sent in clear text and vulnerable to theft or corruption by hackers. In recent years, there has been a concerted effort by ISPs and organizations to support StartTLS for all email communication over the Internet. According to Google’s Transparency Report, Google is able to send 85% of all outbound email traffic securely over TLS and 91% of emails sent to Google are sent over TLS. Based on this, it appears we are getting close to having “secure by default” for all email communication, but issues with Opportunistic TLS still remain.
Making Progress but Room for Improvement
The initiative by ISPs and organizations to support StartTLS and the attention they’re bringing to the insecurity of email are positive advancements, but for organizations that send protected health information, personally identifiable information or confidential business information in email communication, there are issues with the security provided by Opportunistic TLS. The most critical problem is that when a sending mail server issues the StartTLS request to a receiving mail server, the request is sent over an unsecure connection, providing the opportunity for a Man-In-The-Middle (MITM) attack.
One type of MITM attack is a “downgrade attack,” where the attacker simply intercepts the StartTLS request and either removes or modifies the StartTLS command so that the establishment of TLS fails. Because Opportunistic TLS will still send the email if TLS is not available, the email is sent in the clear and unprotected and the attacker then has the opportunity to intercept or read the email communication.
Another type of attack involves DNS poisoning, where an attacker modifies an organization’s MX record such that it contains the name of the attacker’s mail server. This attack works, because StartTLS does not specify full certificate authentication. The only requirement is that the server name match what was found in the MX record. The sending mail server is able to successfully establish a TLS connection, but the connection is actually to the attacker’s mail server and not the intended recipient’s mail server.
It is possible to configure TLS such that full certificate authentication is implemented. This is typically called “Mandatory TLS” and is used by organizations when sending email with strategic partners. Mandatory TLS eliminates the vulnerabilities described above but requires due diligence by the sending and receiving organizations to ensure their TLS connectivity is always available and their certificates are constantly valid. Unlike Opportunistic TLS, Mandatory TLS will reject or bounce the email if TLS is not available or the certificate authentication fails. For this reason Mandatory TLS is only used between organizations that have agreed to accept the risk of emails bouncing if the connection fails.
So how can we collectively improve standards to reach a Secure by Default state? Stay tuned for our next blog post to understand what is needed and what steps you can take until we meet the standard.