Opportunistic TLS

Last updated

Opportunistic TLS (Transport Layer Security) refers to extensions in plain text communication protocols, which offer a way to upgrade a plain text connection to an encrypted (TLS or SSL) connection instead of using a separate port for encrypted communication. Several protocols use a command named "STARTTLS" for this purpose. It is a form of opportunistic encryption and is primarily intended as a countermeasure to passive monitoring.

Contents

The STARTTLS command for IMAP and POP3 is defined in RFC   2595, for SMTP in RFC   3207, for XMPP in RFC   6120 and for NNTP in RFC   4642. For IRC, the IRCv3 Working Group defined a STARTTLS extension, though it was later deprecated. [1] FTP uses the command "AUTH TLS" defined in RFC   4217 and LDAP defines a protocol extension OID in RFC   2830. HTTP uses an upgrade header.

Layering

TLS is application-neutral; in the words of RFC   5246:

One advantage of TLS is that it is application protocol independent. Higher-level protocols can layer on top of the TLS protocol transparently. The TLS standard, however, does not specify how protocols add security with TLS; the decisions on how to initiate TLS handshaking and how to interpret the authentication certificates exchanged are left to the judgment of the designers and implementors of protocols that run on top of TLS. [2]

The style used to specify how to use TLS matches the same layer distinction that is also conveniently supported by several library implementations of TLS. E.g., the RFC   3207 SMTP extension illustrates with the following dialog how a client and server can start a secure session: [3] 

  S: <waits for connection on TCP port 25>   C: <opens connection>   S: 220 mail.example.org ESMTP service ready   C: EHLO client.example.org   S: 250-mail.example.org offers a warm hug of welcome   S: 250 STARTTLS   C: STARTTLS   S: 220 Go ahead   C: <starts TLS negotiation>   C & S: <negotiate a TLS session>   C & S: <check result of negotiation>   C: EHLO client.example.org [4]    . . .

The last EHLO command above is issued over a secure channel. Note that authentication is optional in SMTP, and the omitted server reply may now safely advertise an AUTH PLAIN SMTP extension, which is not present in the plain-text reply.

SSL ports

Besides the use of opportunistic TLS, a number of TCP ports were defined for SSL-secured versions of well-known protocols. These establish secure communications and then present a communication stream identical to the old un-encrypted protocol. Separate SSL ports have the advantage of fewer round-trips; also less meta-data is transmitted in unencrypted form. [5] Some examples include:

ProtocolPurposeNormal portSSL variantSSL port
SMTP Send email25/587 SMTPS 465
POP3 Retrieve email110 POP3S 995
IMAP Read email143 IMAPS 993
NNTP News reader119/433 NNTPS 563
LDAP Directory Access389 LDAPS 636
FTP File transfer21 FTPS 990

At least for the email related protocols, RFC   8314 favors separate SSL ports instead of STARTTLS.

Weaknesses and mitigations

Opportunistic TLS is an opportunistic encryption mechanism. Because the initial handshake takes place in plain text, an attacker in control of the network can modify the server messages via a man-in-the-middle attack to make it appear that TLS is unavailable (called a STRIPTLS attack). Most SMTP clients will then send the email and possibly passwords in plain text, often with no notification to the user.[ citation needed ] In particular, many SMTP connections occur between mail servers, where user notification is not practical.

In September 2014, two ISPs in Thailand were found to be doing this to their own customers. [6] [7] In October 2014, Cricket Wireless, a subsidiary of AT&T, was revealed to be doing this to their customers. This behavior started as early as September 2013 by Aio Wireless, who later merged with Cricket where the practice continued. [8] [6]

STRIPTLS attacks can be blocked by configuring SMTP clients to require TLS for outgoing connections (for example, the Exim Message transfer agent can require TLS via the directive "hosts_require_tls" [9] ). However, since not every mail server supports TLS, it is not practical to simply require TLS for all connections.

An example of a STRIPTLS attack of the type used in Thai mass surveillance technology: [10]

Supposed the client side supports it (name resolution of the client and upstream DNS server of the client) this problem can be addressed by DNS-based Authentication of Named Entities (DANE), a part of DNSSEC, and in particular by RFC   7672 for SMTP. DANE allows to advertise support for secure SMTP via a TLSA record. This tells connecting clients they should require TLS, thus preventing STRIPTLS attacks. The STARTTLS Everywhere project from the Electronic Frontier Foundation works in a similar way. However, DNSSEC, due to deployment complexities and peculiar[ clarification needed ] criticism, [11] faced a low adoption rate and a new protocol called SMTP MTA Strict Transport Security or MTA-STS has been drafted [12] by a group of major email service providers including Microsoft, Google and Yahoo. MTA-STS does not require the use of DNSSEC to authenticate DANE TLSA records but relies on the certificate authority (CA) system and a trust-on-first-use (TOFU) approach to avoid interceptions. The TOFU model reduces complexity but without the guarantees on first use offered by DNSSEC. In addition, MTA-STS introduces a mechanism for failure reporting and a report-only mode, enabling progressive roll-out and auditing for compliance.

Popularity

Following the revelations made by Edward Snowden in light of the global mass surveillance scandal, popular email providers have bettered their email security by enabling STARTTLS. [13] Facebook reported that after enabling STARTTLS and encouraging other providers[ ambiguous ] to do the same, until Facebook discontinued its email service in February 2014, 95% of outbound email was encrypted with both Perfect Forward Secrecy and strict certificate validation. [14]

Related Research Articles

<span class="mw-page-title-main">HTTPS</span> Extension of the HTTP communications protocol to support TLS encryption

Hypertext Transfer Protocol Secure (HTTPS) is an extension of the Hypertext Transfer Protocol (HTTP). It uses encryption for secure communication over a computer network, and is widely used on the Internet. In HTTPS, the communication protocol is encrypted using Transport Layer Security (TLS) or, formerly, Secure Sockets Layer (SSL). The protocol is therefore also referred to as HTTP over TLS, or HTTP over SSL.

In computing, the Post Office Protocol (POP) is an application-layer Internet standard protocol used by e-mail clients to retrieve e-mail from a mail server. Today, POP version 3 (POP3) is the most commonly used version. Together with IMAP, it is one of the most common protocols for email retrieval.

The Simple Mail Transfer Protocol (SMTP) is an Internet standard communication protocol for electronic mail transmission. Mail servers and other message transfer agents use SMTP to send and receive mail messages. User-level email clients typically use SMTP only for sending messages to a mail server for relaying, and typically submit outgoing email to the mail server on port 587 or 465 per RFC 8314. For retrieving messages, IMAP is standard, but proprietary servers also often implement proprietary protocols, e.g., Exchange ActiveSync.

In computing, a handshake is a signal between two devices or programs, used to, e.g., authenticate, coordinate. An example is the handshaking between a hypervisor and an application in a guest virtual machine.

<span class="mw-page-title-main">Email client</span> Computer program used to access and manage a users email

An email client, email reader or, more formally, message user agent (MUA) or mail user agent is a computer program used to access and manage a user's email.

The Network News Transfer Protocol (NNTP) is an application protocol used for transporting Usenet news articles (netnews) between news servers, and for reading/posting articles by the end user client applications. Brian Kantor of the University of California, San Diego, and Phil Lapsley of the University of California, Berkeley, wrote RFC 977, the specification for the Network News Transfer Protocol, in March 1986. Other contributors included Stan O. Barber from the Baylor College of Medicine and Erik Fair of Apple Computer.

Transport Layer Security (TLS) is a cryptographic protocol designed to provide communications security over a computer network. The protocol is widely used in applications such as email, instant messaging, and voice over IP, but its use in securing HTTPS remains the most publicly visible.

FTPS is an extension to the commonly used File Transfer Protocol (FTP) that adds support for the Transport Layer Security (TLS) and, formerly, the Secure Sockets Layer cryptographic protocols.

<span class="mw-page-title-main">Forward secrecy</span> Practice in cryptography

In cryptography, forward secrecy (FS), also known as perfect forward secrecy (PFS), is a feature of specific key-agreement protocols that gives assurances that session keys will not be compromised even if long-term secrets used in the session key exchange are compromised, limiting damage. For HTTPS, the long-term secret is typically the private key of the server. Forward secrecy protects past sessions against future compromises of keys or passwords. By generating a unique session key for every session a user initiates, the compromise of a single session key will not affect any data other than that exchanged in the specific session protected by that particular key. This by itself is not sufficient for forward secrecy which additionally requires that a long-term secret compromise does not affect the security of past session keys.

The comparison of mail servers covers mail transfer agents (MTAs), mail delivery agents, and other computer software that provide e-mail services.

Opportunistic encryption (OE) refers to any system that, when connecting to another system, attempts to encrypt communications channels, otherwise falling back to unencrypted communications. This method requires no pre-arrangement between the two systems.

Email encryption is encryption of email messages to protect the content from being read by entities other than the intended recipients. Email encryption may also include authentication.

Server Name Indication (SNI) is an extension to the Transport Layer Security (TLS) computer networking protocol by which a client indicates which hostname it is attempting to connect to at the start of the handshaking process. The extension allows a server to present one of multiple possible certificates on the same IP address and TCP port number and hence allows multiple secure (HTTPS) websites to be served by the same IP address without requiring all those sites to use the same certificate. It is the conceptual equivalent to HTTP/1.1 name-based virtual hosting, but for HTTPS. This also allows a proxy to forward client traffic to the right server during TLS/SSL handshake. The desired hostname is not encrypted in the original SNI extension, so an eavesdropper can see which site is being requested. The SNI extension was specified in 2003 in RFC 3546

DNSCurve is a proposed secure protocol for the Domain Name System (DNS), designed by Daniel J. Bernstein. It encrypts and authenticates DNS packets between resolvers and authoritative servers.

A cipher suite is a set of algorithms that help secure a network connection. Suites typically use Transport Layer Security (TLS) or its deprecated predecessor Secure Socket Layer (SSL). The set of algorithms that cipher suites usually contain include: a key exchange algorithm, a bulk encryption algorithm, and a message authentication code (MAC) algorithm.

SMTP Authentication, often abbreviated SMTP AUTH, is an extension of the Simple Mail Transfer Protocol (SMTP) whereby a client may log in using any authentication mechanism supported by the server. It is mainly used by submission servers, where authentication is mandatory.

SMTPS (Simple Mail Transfer Protocol Secure) is a method for securing the SMTP using transport layer security. It is intended to provide authentication of the communication partners, as well as data integrity and confidentiality.

DNS-based Authentication of Named Entities (DANE) is an Internet security protocol to allow X.509 digital certificates, commonly used for Transport Layer Security (TLS), to be bound to domain names using Domain Name System Security Extensions (DNSSEC).

A downgrade attack, also called a bidding-down attack, or version rollback attack, is a form of cryptographic attack on a computer system or communications protocol that makes it abandon a high-quality mode of operation in favor of an older, lower-quality mode of operation that is typically provided for backward compatibility with older systems. An example of such a flaw was found in OpenSSL that allowed the attacker to negotiate the use of a lower version of TLS between the client and server. This is one of the most common types of downgrade attacks. Opportunistic encryption protocols such as STARTTLS are generally vulnerable to downgrade attacks, as they, by design, fall back to unencrypted communication. Websites which rely on redirects from unencrypted HTTP to encrypted HTTPS can also be vulnerable to downgrade attacks, as the initial redirect is not protected by encryption.

<span class="mw-page-title-main">Mailfence</span> Encrypted email service

Mailfence is secure encrypted email service that offers OpenPGP based end-to-end encryption and digital signatures. It was launched in November 2013 by Belgium-based company ContactOffice Group that has been operating an online collaboration suite since 1999.

References

  1. ↑ "tls Extension". IRCv3 Working Group. 2012. Retrieved 6 April 2024.
  2. ↑ Tim Dierks; Eric Rescorla (August 2008). "The Transport Layer Security (TLS) Protocol". RFC Editor . Retrieved 8 October 2009.
  3. ↑ Paul Hoffman (February 2002). "SMTP Service Extension for Secure SMTP over Transport Layer Security". RFC Editor . Retrieved 8 October 2009.
  4. ↑ The last line in the example added for clarity. See e.g. the thread started by Paul Smith (26 January 2009). "STARTTLS & EHLO". ietf-smtp mailing list. Internet Mail Consortium . Retrieved 16 September 2015.
  5. ↑ Dovecot SSL documentation: http://wiki2.dovecot.org/SSL
  6. 1 2 Hoffman-Andrews, Jacob (11 November 2014). "ISPs Removing Their Customers' Email Encryption". Electronic Frontier Foundation . Retrieved 19 January 2019.
  7. ↑ "Google, Yahoo SMTP email servers hit in Thailand". 12 September 2014. Retrieved 31 July 2015.
  8. ↑ "The FCC Must Prevent ISPs From Blocking Encryption". 4 November 2014. Retrieved 31 July 2015.
  9. ↑ "Exim Internet Mailer - The smtp transport". exim.org. hosts_require_tls - Exim will insist on using a TLS session when delivering to any host that matches this list.
  10. ↑ "Who's That Knocking at my door? Understanding Surveillance in Thailand" (PDF). Privacy International: 21. January 2017. Retrieved 7 February 2020.
  11. ↑ Thomas Ptacek (18 March 2016). "Against DNSSEC".
  12. ↑ Ramakrishnan, Binu; Brotman, Alexander; Jones, Janet; Margolis, Daniel; Risher, Mark. "SMTP MTA Strict Transport Security (MTA-STS)". tools.ietf.org. Retrieved 22 February 2019.
  13. ↑ Peterson, Andrea (12 August 2014). "Facebook's security chief on the Snowden effect, the Messenger app backlash and staying optimistic". The Washington Post . Retrieved 2 November 2014.
  14. ↑ Cohen, David (19 August 2014). "Facebook: 95% of Notification Emails Encrypted Thanks to Providers' STARTTLS Deployment". allfacebook.com. Archived from the original on 22 September 2014.
This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.