Communications protocol security extension
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
.
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
[
edit
]
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
[
edit
]
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:
At least for the email related protocols,
RFC
8314
favors separate SSL ports instead of STARTTLS.
Weaknesses and mitigations
[
edit
]
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]
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
[
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
[
edit
]
| 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.
[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]
References
[
edit
]
- ^
"tls Extension"
. IRCv3 Working Group. 2012
. Retrieved
6 April
2024
.
- ^
Tim Dierks; Eric Rescorla (August 2008).
"The Transport Layer Security (TLS) Protocol"
.
RFC Editor
. Retrieved
8 October
2009
.
- ^
Paul Hoffman (February 2002).
"SMTP Service Extension for Secure SMTP over Transport Layer Security"
.
RFC Editor
. Retrieved
8 October
2009
.
- ^
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
.
- ^
Dovecot
SSL documentation:
http://wiki2.dovecot.org/SSL
- ^
a
b
Hoffman-Andrews, Jacob (11 November 2014).
"ISPs Removing Their Customers' Email Encryption"
.
Electronic Frontier Foundation
. Retrieved
19 January
2019
.
- ^
"Google, Yahoo SMTP email servers 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
.
- ^
"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. January 2017
. Retrieved
7 February
2020
.
- ^
Thomas Ptacek (18 March 2016).
"Against DNSSEC"
.
- ^
Ramakrishnan, Binu; Brotman, Alexander; Jones, Janet; Margolis, Daniel; Risher, Mark.
"SMTP MTA Strict Transport Security (MTA-STS)"
.
tools.ietf.org
. Retrieved
22 February
2019
.
- ^
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
.
- ^
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.
External links
[
edit
]
|
---|
Protocols and technologies
| |
---|
Public-key infrastructure
| |
---|
See also
| |
---|
History
| |
---|
Implementations
| |
---|
Notaries
| |
---|
Vulnerabilities
| Theory
| |
---|
Cipher
| |
---|
Protocol
| |
---|
Implementation
| |
---|
|
---|