TLS in the Wild: An Internet-wide Analysis of TLS-based Protocols for Electronic Communication

Email and chat still constitute the majority of electronic communication on the Internet. The standardisation and acceptance of protocols such as SMTP, IMAP, POP3, XMPP, and IRC has allowed to deploy servers for email and chat in a decentralised and interoperable fashion. These protocols can be secured by providing encryption with TLS-directly or via the STARTTLS extension. X.509 PKIs and ad hoc methods can be leveraged to authenticate communication peers. However, secure configuration is not straight-forward and many combinations of encryption and authentication mechanisms lead to insecure deployments and potentially compromise of data in transit. In this paper, we present the largest study to date that investigates the security of our email and chat infrastructures. We used active Internet-wide scans to determine the amount of secure service deployments, and employed passive monitoring to investigate to which degree user agents actually choose secure mechanisms for their communication. We addressed both client-to-server interactions as well as server-to-server forwarding. Apart from the authentication and encryption mechanisms that the investigated protocols offer on the transport layer, we also investigated the methods for client authentication in use on the application layer. Our findings shed light on an insofar unexplored area of the Internet. Our results, in a nutshell, are a mix of both positive and negative findings. While large providers offer good security for their users, most of our communication is poorly secured in transit, with weaknesses in the cryptographic setup and especially in the choice of authentication mechanisms. We present a list of actionable changes to improve the situation. * The work was carried out during the first author's time at Data61/CSIRO. in 2018 [11] . As for chat, the most widely used standardbased networks are IRC group chats and the XMPP instant messaging and multi-user conferencing network. In their early days, email protocols such as SMTP, POP3, and IMAP were designed with no special focus on security. In particular, authentication in SMTP was introduced a while after the protocol's standardisation, initially as a way to fight spam. User agents started to move towards encryption and authenticated connections gradually, using the then-new SSL 3 and later the TLS protocols to protect the transport layer. SSL/TLS can provide authentication, integrity, and confidentiality. Where SSL/TLS is not used, user credentials may be transmitted in plaintext, with no protection against eavesdropping, and message bodies can be tampered with (unless end-to-end mechanisms like OpenPGP or S/MIME are used, which is a comparatively rare setup). Although SSL/TLS support mutual authentication, the most common usage pattern in the context of email and chat is unilateral authentication: only the responder of a communication is authenticated on the transport layer. The primary reason for this is the protocols' reliance on an X.509 Public Key Infrastructure (PKI) for authentication purposes 1 and the subsequent need for client certification, an operation that is expensive in practice, introduces much administrative overhead, and often also requires user education. In most cases, initiators are authenticated on the application layer instead, i.e., by mechanisms that are specific to the application layer protocol in question. Passwords schemes are the most common choice, although any mechanism that is supported by both initiator and responder is possible. Different password schemes offer varying levels of security-e.g., the password may be sent without further protection over the SSL/TLS channel, or a challenge-response mechanism like CRAM, or even SCRAM, may be used. The latter is particularly elegant as it does not require the responder to store the actual password, nor is the password ever sent over the connection. The choice of password scheme has a profound influence on security in case of missing authentication on the level of SSL/TLS. The proper in-band authentication of the responder is a 1 Variants of TLS that support other forms of authentication have been standardised, but seem to be rarely used. Permission to freely reproduce all or part of this paper for noncommercial purposes is granted provided that copies bear this notice and the full citation on the first page. Reproduction for commercial purposes is strictly prohibited without the prior written consent of the Internet Society, the first-named author (for reproduction of an entire paper only), and the author's employer if the paper was prepared within the scope of employment.