STARTTLS
STARTTLS describes a method for initiating the encryption of a network communication using Transport Layer Security (TLS). If no additional protective measures are implemented against a downgrade attack , this is an opportunistic encryption .
STARTTLS dates back to 1999 and was supposed to force encrypted transmissions back then. From 2018, only fully encrypted transmissions are recommended, since with STARTTLS the first connection is always established in plain text and it also no longer offers any advantages over TLS, the setting "SSL / TLS" is generally recommended in e-mail clients and therefore by STARTTLS discouraged.
functionality
The client first establishes an unencrypted network connection to the server and uses the port provided for plain text communication. If the server signals support for STARTTLS, the client sends the STARTTLS command. The two communication partners start with the TLS handshake and negotiate encryption. The application log is then continued in encrypted form.
STARTTLS differs from implicit TLS in which the TLS handshake starts immediately after the connection is established, without any plain text communication. The use of TLS is implied here by using a dedicated port that is used exclusively for encrypted communication.
With STARTTLS, however, it is explicitly negotiated whether TLS should be used. When STARTTLS was created in 1999, unencrypted data transmission was widespread on the Internet. In this context, STARTTLS had the advantage that it represents an upgrade mechanism that is easy to implement in order to use TLS, if available, and otherwise fall back to an unencrypted transmission ( opportunistic encryption ). Another advantage is the saving of port numbers with IANA , since in contrast to implicit TLS, only one port is required for both encrypted and unencrypted transmission.
The main disadvantage of STARTTLS is that this upgrade mechanism is vulnerable to man-in-the-middle attacks . The attacker can prevent TLS encryption by manipulating the plain text commands. Additional measures are required to protect against such a downgrade attack , for example DANE or MTA-STS . A disadvantage in connection with a firewall can be that deep packet inspection is required at the application layer in order to differentiate between encrypted and unencrypted connections.
In the years that followed, TLS continued to spread. With a re-evaluation in 2018, the STARTTLS developers now prefer implicit TLS. Transmission in plain text is completely discouraged.
STARTTLS has been specified as an extension for the Simple Mail Transfer Protocol (SMTP) since 1999 . The client starts the connection with the keyword known from Extended SMTPEHLO . If the server is supported, it lists STARTTLS as an extension. The client is then free STARTTLSto initiate the TLS handshake using the keyword .
The following example shows an SMTP connection with STARTTLS ( server blue , client green ):
220 mx1001.wikimedia.org ESMTP Exim 4.89 Mon, 13 Jan 2020 23:12:13 +0000 EHLO client.example.org 250-mx1001.wikimedia.org Hello client.example.org [2001:db8:13b:2048::113] 250-SIZE 52428800 250-8BITMIME 250-PIPELINING 250-STARTTLS 250 HELP STARTTLS 220 TLS go ahead [hier beginnt der TLS-Handshake]
Shortly after SMTP, the specification for the Internet Message Access Protocol (IMAP) followed, as well as the Application Configuration Access Protocol (ACAP) and Post Office Protocol (POP) , which are no longer common . The latter is used as a keyword STLSbecause POP commands are always four letters long.
Ports
There are also port assignments for implicit TLS. The following table lists the port numbers assigned by the IANA . The letter 'S' after the protocol designation indicates the variant with implicit TLS.
| Protocol (port) | Protocol with implicit TLS (port) | comment |
|---|---|---|
| SMTP (587, partly also 25) | SMTPS (465) | Only applies to mail submission . |
| IMAP (143) | IMAPS (993) | |
| POP3 (110) | POP3S (995) |
RFC 8314 recommends the use of implicit TLS for all communication between the mail user agent and the e-mail provider . In the case of SMTP, this recommendation relates exclusively to mail submission (user to provider), since the port number can only be configured there. The RFC makes no statements about SMTP for mail transfer (provider to provider). Since the protocol for the latter is set to port 25 and cannot be changed by the communication partner, only STARTTLS can be used for this.
For historical reasons, in addition to SMTPS, a Cisco protocol from the multicast environment is assigned to TCP port 465. Section 7.3 of RFC 8314 provides an explanation for this .
Downgrade attack
A man-in-the-middle attacker can disrupt TLS encryption by removing or overwriting the STARTTLS extension, thereby pretending that the server does not support STARTTLS. This attack is also known as a stripping attack or STRIPTLS and happened, for example, in December 2008 at the cell phone provider O2. If the client continues processing in the unencrypted connection, it is possible for the attacker to read and manipulate the e-mails unnoticed.
Protection against this attack is comparatively easy with Mail Submission by configuring the mail user agent in such a way that it requires encryption. For example, earlier Thunderbird versions had the choice between “TLS, if possible” and “TLS” (in the sense of “force TLS”).
With Mail Transfer, TLS cannot simply be enforced, as it is not clear to an e-mail provider whether the destination server really supports TLS or not. The server operator can use the DANE or MTA-STS method to signal this information.
DANE
DNS-based Authentication of Named Entities (DANE) binds an e-mail server to a PKIX certificate that is issued to a server or a certification authority. The certificate can also be self-signed. The server operator must store the fingerprint of the certificate at a defined location in the domain name system and use DNSSEC . With the DNS entry, the server operator signals the support of STARTTLS and prohibits a downgrade to unencrypted transmission.
MTA-STS
In order to provide e-mail providers with an alternative method to DANE, the IETF SMTP has designed MTA Strict Transport Security ( MTA-STS ). MTA-STS requires the use of PKIX certificates for the mail server as well as for a web server on which the policy of a domain is stored. The owner of an e-mail domain signals the existence of a policy and thus the use of MTA-STS by means of a DNS entry that can optionally be DNSSEC-signed. Without DNSSEC, the process is vulnerable to downgrade attacks through DNS spoofing .
MTA-STS requires the use of TLS version 1.2 or higher. The mail server certificate must be issued to the host name from the MX resource record . In contrast to DANE, it is not possible to use self-issued certificates.
The following example shows a DNS entry for the domain example.com:
_mta-sts.example.com. IN TXT "v=STSv1; id=20160831085700Z;"
The "id" field is used to determine whether a policy has changed. The policy is https://mta-sts.example.com/.well-known/mta-sts.txtstored under the URL and looks, for example, as follows:
version: STSv1 mode: enforce mx: mail.example.com mx: *.example.net mx: backupmx.example.com max_age: 604800
With the "enforce" policy mode, the domain owner signals that STARTTLS is being used with a trustworthy server certificate and that no downgrade to unencrypted transmission is allowed.
MTA-STS and DANE can be used in parallel. MTA-STS is specified so that it does not override a failed DANE test.
SMTP TLS reporting
In parallel to MTA-STS, the IETF has introduced SMTP TLS Reporting ( TLSRPT ), a procedure for automated reporting on the use of TLS. The purpose is for an email provider to know about TLS errors in incoming SMTP connections, which can be caused by a misconfiguration, interoperability problems or downgrade attacks. The reporting thus closes an information gap, as it is difficult for an email provider to see whether there is currently no regular email traffic or whether the traffic is impaired by a technical problem.
Similar to DMARC reporting, TLS reporting is configured using a TXT resource record in the DNS. The following example shows the TXT record for an email domain example.com :
_smtp._tls.example.com. IN TXT "v=TLSRPTv1;rua=mailto:reports@example.com"
In addition to the delivery of reports by e-mail, HTTPS is also specified as a delivery method. The reports use the JSON text format with a schema related to HPKP reports. The report contains statistics on successful and faulty TLS connections, as well as which DANE or MTA-STS policy was applied.
More protocols
For HTTP, there is a procedure comparable to STARTTLS with RFC 2817 for establishing TLS connections. Usually, however, implicit HTTPS according to RFC 2818 is used here.
With LDAP ( RFC 4511 ), FTP ( RFC 4217 ) and XMPP ( RFC 6120 ) as well as NNTP ( RFC 4642 ), the encryption can be initiated using the STARTTLS command. There is a draft for Telnet.
Norms and standards
- RFC 2487 (1999, first version, obsolete): SMTP Service Extension for Secure SMTP over TLS.
- RFC 3207 (2002, second version): SMTP Service Extension for Secure SMTP over Transport Layer Security.
- RFC 7817 (2016, additions): Updated Transport Layer Security (TLS) Server Identity Check Procedure for Email-Related Protocols.
- RFC 8314 (2018, recommendation for SMTPS instead of STARTTLS) Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access
Web links
- SMTP TLS Tests and Tools in German (to test self-used email providers for TLS encryption)
- Jürgen Schmidt: Forced encryption for e-mail transport. heise online , September 28, 2018.
- Differences between SSL, TLS and STARTTLS
Individual evidence
- ↑ a b c d https://tools.ietf.org/html/rfc8314
- ↑ E-Mails (general) - Thunderbird - SMTP, POP3, IMAP. In: Privacy manual. Retrieved May 14, 2020 .
- ↑ a b https://tools.ietf.org/html/rfc2487
- ↑ a b https://tools.ietf.org/html/rfc2595
- ↑ Port Numbers . Internet Assigned Numbers Authority. September 14, 2009. Retrieved September 15, 2009.
- ↑ Intervention in e-mail encryption by the O2 cellular network . Heise publishing house. September 17, 2008. Retrieved August 22, 2014.
- ↑ a b https://tools.ietf.org/html/rfc8461
- ↑ https://tools.ietf.org/html/rfc8460
- ↑ DRAFT Telnet START-TLS option . Internet Engineering Task Force - Jeffrey Altman. December 15, 2006. Retrieved October 14, 2019.