A First Large-Scale Analysis on Usage of MTA-STS
Total Page:16
File Type:pdf, Size:1020Kb
Extended Abstract: A First Large-scale Analysis on Usage of MTA-STS Dennis Tatang, Robin Flume, and Thorsten Holz Ruhr-Universit¨atBochum, Germany Abstract. Nowadays, email is still the most popular communication channel of the Internet. It is based on Simple Mail Transfer Protocol (SMTP), which lacks basic security properties such as confidentiality and authenticity despite its ever-growing importance. This results in spam and frequent phishing attacks, often with spoofed sender email addresses to appear more trustworthy, as well as non-encrypted transmissions by default. To address these known problems, additional protocols such as STARTTLS have been developed. STARTTLS enables transport encryp- tion with Transport Layer Security (TLS) for SMTP sessions between two email servers. However, an attacker can take advantage of the fact that the encryption is opportunistic and the STARTTLS command is sent in plain. Therefore, it can be stripped out of the communication, resulting in an inevitable plaintext transmission of the email message it- self. This attack is referred to as TLS downgrade. The new Mail Transfer Agent Strict Transport Security (MTA-STS) protocol targets the pre- vention of TLS downgrades for incoming SMTP sessions. In this paper, we conduct the first large-scale, longitudinal measurement study on the adoption of MTA-STS. We show that it is activated by 0.0124% out of 1.76 million scanned domains, with a lower bound of 45.4% for the growth of the adoption rate within five months. Keywords: Internet measurement, DNS, MTA-STS 1 Introduction Email usage in private and commercial everyday life has increased continuously since its invention in 1971. Studies showed that besides information not worthy of protection, sensitive documents and data (e.g., business documents, pass- words, private photos, etc.) are exchanged via this communication medium [2, 19]. The foundation builds is the Simple Mail Transfer Protocol (SMTP). How- ever, despite the ever-increasing popularity of email, it does not provide any security mechanisms (neither for the verification of communication partners nor the protection of privacy). Accordingly, emails are exchanged between email servers via SMTP unauthenticated and unencrypted by default. Increasing con- cerns in recent years came along with this. A solution is provided by protocols such as OpenPGP or S/MIME, which can encrypt emails end-to-end. However, this requires users to take active steps when sending emails to ensure that the 2 D. Tatang et al. content of the messages is encrypted. Another limitation is that both partici- pants must comply with all technical requirements. Therefore, Domain Name System (DNS)-based SMTP extensions such as SPF, DMARC, or DKIM are of particular importance for secure email transmission. Another SMTP extension is STARTTLS, which can be used to initiate transport encryption using Transport Layer Security (TLS) after the connection has been established. This ensures the integrity of the messages, at least during their direct transmission between the servers of the sender and recipient domain. The problem is that STARTTLS only offers opportunistic encryption: If one of the two communication partners does not support TLS or if an error occurs in the TLS handshake, the email is transmitted in plain text. Furthermore, TLS encryption can be prevented by actively intervening in the correspondence. Ultimately, an end-user cannot de- termine whether or not a given email is encrypted during transport. For several years now, domain operators can use DNS-based Authentication of Named En- tities (DANE) to store the fingerprints of the X.509 certificates used by their mail servers in the DNS. This allows the servers to be authenticated and their TLS support to be implied. However, DANE requires Domain Name System Security Extensions (DNSSEC). Therefore, a new protocol called Mail Transfer Agent Strict Transport Security (MTA-STS) was standardized at the end of 2018 (RFC 8461 [14]). It aims at being able to require TLS encryption of incoming SMTP connections on the domain's mail servers. In this way, attacks on TLS encryption (TLS downgrades) as well as plain text transmissions due to lack of TLS support by the sender should be prevented. Given these shortcomings, an empirical study can shed light on the actual deployment in practice. In this paper, we measure the distribution and relevance of the still new protocol for the first time. According to a blog post by SocketLabs, it is already widely used [20]. SocketLabs and also Google's Gmail service [12] support it since April and May 2019, respectively. For our measurement study, we implement a crawler with which the required data is gathered. The number of domains that have MTA-STS activated is also compared with the number of domains that have SPF and DMARC protocols installed. Furthermore, we examined in more detail the MTA-STS settings used in practice. Although it is possible to activate the protocol with a few simple settings, misconfigurations may occur, limiting or eliminating the desired security. In the course of the measurements, the mail servers used by the top one million domains are also examined for their STARTTLS support, which is a necessity for the use of MTA-STS. In summary, we make the following main contributions: { We present the first large-scale study on the adoption of MTA-STS. { We gather and analyze protocol configurations used in practice in detail. { We discuss issues of MTA-STS itself and argue that it might be already obsolete before ever widely in use. 2 Security-related Extensions for E-Mail In order to solve the problems of SMTP (confidentiality as well as authentication and integrity), many different protocols have been developed in recent years. Extended Abstract: A First Large-scale Analysis on Usage of MTA-STS 3 Encryption Encryption is used to ensure the confidentiality of transmitted data. A distinction is made between transport encryption (e.g., STARTTLS) and end- to-end encryption (OpenPGP, S/MIME). Transport encryption is relevant to our work. The standard for transport encryption is the TLS protocol. An extension that TLS uses for transport encryption of SMTP traffic is STARTTLS. It at- tempts a TLS handshake between the communication partners. If the handshake fails, the communication is performed without transport encryption. Therefore, it is opportunistic encryption that protects against passive attackers only. As soon as we consider active attackers, a so-called STARTTLS downgrade attack is possible. In the context of email communication, this attack becomes par- ticularly important, as the opportunistic encryption achieved by STARTTLS is being circumvented, and as a result, messages can be read by third parties. It is known that this attack is used in practice by intelligence agencies, Internet ser- vice providers, and mobile phone operators [5, 6]. Another extension is SMTPS. In this case, data is only exchanged after a successful TLS handshake. Mail Transfer Agent Strict Transport Security (MTA-STS). This protocol is used to indicate support for STARTTLS. It also defines how MTA-STS com- pliant senders must behave if encrypted communication fails. Thus, the goal of MTA-STS is to prevent the STARTTLS downgrade attack. MTA-STS essentially consists of two components. These are a TXT resource record in the DNS and a MTA-STS policy. Both consist of key/value pairs separated by semicolons, which are used to configure the protocol for a given domain. The MTA-STS record is used to inform the sending MTA that MTA-STS is basically activated and thus a policy is available for retrieval. It consists of at least two mandatory parameters: (i) the protocol version used and (ii) an identifier (ID). It is crucial that the ID for a domain must be unique. This is because the ID enables senders to find out with a single DNS query whether their cached policy for the target domain needs to be updated. The MTA-STS policy consists of four defined keys (version, mode, mx, max age). So far, only STSv1 version is supported. The possible values for the mode are: enforce, testing, none. The key mx indicates that the corresponding mail server supports the START- TLS command in principle. The numeric value of max age indicates in sec- onds the maximum time a policy may be cached by the sender. The policy should not exceed the maximum size of 64 kilobytes. It must be delivered via web server using the .well-known path defined in RFC 8615 as media type text/plain. The generic Uniform Resource Identifier (URI) of the policy is mta- sts.[domain].[tld]/.well-known/mta-sts.txt. Authentication. Integrity and authenticity are two other important protection goals, neither of which are met by SMTP. Especially against the background of possible sender spoofing and spam, not only the authenticity of the sender is important within the email infrastructure, but also that of the mail server. Protocols for authentication of the sender domain are SPF, DKIM, and DMARC. Another protocol is DNS-based Authentication of Named Entities (DANE). This prevents the impersonation of mail or web servers by fake PKIX certificates. 4 D. Tatang et al. Reporting. The TLS-RPT protocol is defined in RFC 8460 and was developed to extend MTA-STS and DANE with a reporting mechanism [13]. The mes- sages listed in the report can help to identify misconfigurations or even active attacks on the TLS sessions between the MTAs of both parties. In doing so, the report covers errors that occur in the areas of routing, DNS name resolution, STARTTLS parameter negotiation, or policy validation. To enable TLS-RPT, an administrator needs to set another TXT record for the policy domain at smtp. tls.[domain].[tld]. 3 Measurement Approach Crawler Our crawler implements the following two main functions: (i) the verifi- cation of the existence of MTA-STS components (by requesting the correspond- ing DNS TXT records), as well as, (ii) their validation (by gathering via HTTPS accessible MTA-STS policies).