Opportunistic TLS 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 primarily intended as a countermeasure to passive monitoring.
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 de facto definition is documented at the InspIRCd Wiki. FTP uses the command "AUTH TLS" defined in RFC 4217 and LDAP defines a protocol extension OID in RFC 2830.
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.
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:
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 . . .
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.
Before opportunistic TLS was well established, 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. These are no longer recommended, since opportunistic TLS makes more efficient use of scarce port numbers and allows simpler device configuration. On the other hand, SSL ports have the advantage of fewer round-trips; also less meta-data is transmitted in unencrypted form. Some examples include:
|Protocol||Purpose||Normal port||SSL variant||SSL port|
|SMTP||Send email||25/587||SMTPS||465 (legacy)|
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. 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. In October 2014, Aio Wireless, then a subsidiary of Cricket Wireless, was found to be doing this to their customers.
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" ). However, since not every mail server supports TLS, it is not practical to simply require TLS for all connections.
220 smtp.gmail.com ESMTP mail.redacted.com - gsmtp ehlo a 250-smtp.gmail.com at your service, [REDACTED SERVICE] 250-SIZE 35882577 250-8BITMIME # The STARTTLS command is stripped here 250-ENHANCEDSTATUSCODES 250-PIPELINING 250 SMTPUTF8
220 smtp.gmail.com ESMTP - gsmtp ehlo a 250-smtp.gmail.com at your service 250-SIZE 35882577 250-8BITMIME 250-STARTTLS 250-ENHANCEDSTATUSCODES 250-PIPELINING 250 SMTPUTF8
This problem is 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 criticism, faced a low adoption rate and a new protocol called SMTP Strict Transport Security or SMTP STS has been drafted by a group of major email service providers including Microsoft, Google and Yahoo - that got more fine-tuned in its superseded versions. SMTP STS does not requires 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 allows a degree of security similar to that of HPKP, reducing the complexity but without the guarantees on first use offered by DNSSEC. In addition, SMTP STS introduces a mechanism for failure reporting and a report-only mode, enabling progressive roll-out and auditing for compliance.
|This section needs expansion. You can help by adding to it. (May 2016)|
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. Facebook reported that after enabling STARTTLS and encouraging other providers[ambiguous] to do the same, 95% of Facebook's outbound email is encrypted with both Perfect Forward Secrecy and strict certificate validation.
- "STARTTLS Documentation". InspIRCd Wiki. 17 February 2010. Retrieved 21 May 2016.
- Tim Dierks; Eric Rescorla (August 2008). "The Transport Layer Security (TLS) Protocol". RFC Editor. Retrieved 2009-10-08.
- Paul Hoffman (February 2002). "SMTP Service Extension for Secure SMTP over Transport Layer Security". RFC Editor. Retrieved 2009-10-08.
- 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 2015-09-16.
- Dovecot SSL documentation: http://wiki2.dovecot.org/SSL
- Port assignment has been revoked. Paul Hoffman (1998-11-12). "Revoking the smtps TCP port". Internet Mail Consortium. Retrieved 2013-10-09.
- "Google, Yahoo SMTP email severs hit in Thailand". 12 September 2014. Retrieved 31 July 2015.
- "The FCC Must Prevent ISPs From Blocking Encryption". 4 November 2014. Retrieved 31 July 2015.
- Hoffman-Andrews, Jacob (11 November 2014). "ISPs Removing Their Customers' Email Encryption". Retrieved 31 July 2015.
- "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.
- "Who's That Knocking at my door? Understanding Surveillance in Thailand" (PDF). Privacy International: 21. 26 January 2017. Retrieved 27 January 2017.
- Thomas Ptacek (18 March 2016). "Against DNSSEC".
- Peterson, Andrea. "Facebook's security chief on the Snowden effect, the Messenger app backlash and staying optimistic". washingtonpost.com. Washington Post. Retrieved 2 November 2014.
- Cohen, David. "Facebook: 95% of Notification Emails Encrypted Thanks to Providers' STARTTLS Deployment". allfacebook.com. All Facebook. Retrieved 2 November 2014.
- SMTP TLS Tests and Tools (the "Receiver Test" shows dialogs like the one above)
- Verify if a receiving domain has STARTTLS enabled for email and with which security level