StartTLS
IONOS editorial team5 mins
The StartTLS command (also known as STARTSSL, StartSSL or “Opportunistic TLS”) extends the Transport Layer Security (TLS) protocol in order to encrypt the information transmitted using the TLS protocol. StartTLS is mainly used as a protocol extension for communication by e-mail, based on the protocols SMTP, IMAP and POP. HTTP has its own method (specified in RFC 2817), which is very similar to StartTLS. However, the use of HTTPS (RFC 2818) is now more common. As well as the e-mail protocols mentioned, StartTLS can initiate the encryption process with the following methods:
- LDAP (RFC 4511)
- FTP (RFC 4217)
- XMPP (RFC 6120)
- NNTP (RFC 4642)
StartTLS has become the most popular e-mail encryption method among internet providers, as it facilitates the use of many different domains and certificates on one server. The method is not undisputed, as private details such as the IP address are initially sent in unencrypted form. This means man-in-the-middle attacks are possible by overwriting the StartTLS unnoticed by the provider.
- Secures data transfers
- Avoids browser warnings
- Improves your Google ranking
How does StartTLS work?
As an additional command for SSL/TLS, StartTLS offers the major advantage that communication is not restricted with clients that do not support encryption. StartTLS generates far fewer compatibility problems. However, mail programs (clients) must have a procedure on what to do with the data when a server refuses TLS. A further advantage are mutual negotiations regarding encryption, so that automated processes take over in the event of a communication failure. The administrator or user doesn't need to intervene.
The StartTLS method always starts a connection in unencrypted mode on a port configured for plain text. Only after the StartTLS command has been fully executed, the protocol negotiates the encryption with the client. It doesn't need to establish a new connection. Thanks to StartTLS, the port doesn't need to be contacted in the event of a communication error. The client can simply use the StartTLS protocol provided by the mail server.
Disadvantages of the StartTLS protocol become evident with regard to security software. Firewalls must analyze the process at user level to sort encrypted data from unencrypted data. The same applies to proxies that differentiate ports, as the ports are not changed with StartTLS. This makes it harder to carry out the appropriate caching. Sometimes it isn't performed at all.
StartTLS raises some concerns about data protection. Most e-mail programs use the “TLS where possible” option, so that the user does not notice whether or not the connection to the mail server is encrypted. This also increases the risk of a man-in-the-middle attack, as the network operator can simply filter out the StartTLS extension and therefore has the option of logging the data exchange. If the StartTLS command is not executed, data communication is unencrypted - and the user will normally not notice that.
Check our guidebook on man-in-the-middle attacks to see how this spying method works.
It is therefore recommended to perform a careful test in advance to see whether the server is actually StartTLS-capable. You shouldn't start using the protocol regularly until this has been done. If encrypted communication subsequently fails, it will be due to an external problem.
Example: E-mail
A user wants to encrypt an e-mail using TLS. They select the StartTLS protocol in the account configuration settings or the e-mail client account settings to integrate the encryption method flawlessly into normal operations. After sending the e-mail, communication starts:
- The client asks the mail server whether the encryption method is accepted by transmitting “250-STARTTLS”.
- If the feedback is positive (“go ahead”), an encrypted connection is established.
- The client restarts the connection. The e-mail communication is now encrypted.
How can I test StartTLS?
The TLS protocol may use different ports, depending on the provider. StartTLS can easily be integrated into the connection, so that no port switching is required and the encryption method can be easily tested from a suitable terminal. This makes it obvious which port the provider uses for StartTLS. The following command can be used to test whether a mail server accepts StartTLS as an encryption method during normal operations (e.g. in NetCat):
$ nc smtp.test.server smtp
220 Mailserver ESMTP Exim 4.69 Wed, 18 Jul 2018 12:19:15 +0200
ehlo test
250-Mailserver Hello oneandone [10.1.2.73]
250-SIZE 78643200
250-PIPELINING
250-STARTTLS
220-go ahead
250 HELP
Quit
221 Mailserver closing connectionThe “STARTTLS” command is used here to activate encryption. You can also see that private data, such as the IP address, is transmitted in unencrypted form during this process.
The command for OpenSSL looks like this:
$ openssl s_client -host mail.test.server-port 25 -starttls smtp
CONNECTED(00000003)
[...]
250 HELP
ehlo test
250-Mailserver Hello oneandone [10.1.2.73]
250-SIZE 52428800
250-PIPELINING
250-AUTH PLAIN LOGIN
250 HELPHowever, authentication in SMTP is not so easy. In most cases, the “AUTH PLAIN” method can help. To use it, the access data has to be encoded in Base64. The Perl command $ perl -MMIME::Base64 -e 'print encode_base64("\000user-ju\000secret")' is used to generate a code that is subsequently forwarded to the SMTP server (“AUTH PLAIN [Code]”). The test for StartTLS was successful when the server answers with “Authentication succeeded” (including code). Further mail commands can follow.
Testing of the StartTLS on servers or in protocols that are not compatible with OpenSSL can be facilitated by the gnuts-cli tool (from the gnuts-bin).
