What Is STARTTLS and How Does It Work?

We all use email daily, and generally consider it secure, but have you ever wondered how email is securely sent from one server to another? To encrypt your email and help it safely get to your subscribers' inboxes, ESPs use either Transport Layer Security (TLS) or Secure Sockets Layer (SSL) encrypted connection. In this article we’ll discuss the inner workings of secure communication.

What Is STARTTLS?

STARTTLS is a protocol command that tells the email server that the other party (email server or client) wants to switch from an insecure plain text connection to a secure connection using TLS or SSL. This command is used in SMTP and IMAP protocols, whereas the POP3 protocol uses STLS, a slightly different encryption command. We'll look at the differences between TLS and SSL, the STARTTLS process, and learn how to test your program with it.

Why Is STARTTLS Important?

By default, SMTP is not secured, which means that if you send an email over SMTP without using SSL/TLS, it would be easy to intercept your email. It's particularly challenging when transmitting sensitive data such as credentials or banking information.

Using STARTTLS, an email client informs the server they want to encrypt the content of an email message. If the email is intercepted, the content will be nearly impossible to decrypt, since only the email server and client have the key to decode the message.

How Does STARTTLS Work?

The STARTTLS Process

SMTP always starts in an unencrypted state, and the STARTTLS command initiates the server-client negotiation. The communication session between the email client and server is outlined below.

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: <perform a TLS handshake, then reconnect and exchange mail>

What do all these lines account for? Let’s see.

1. The Transmission Control Protocol (TCP) handshake begins the process, allowing the email client and server to initially connect to each other.
2. With “220 ESMTP service ready”, the server indicates that it is ready for further communication.
3. The client sends an "EHLO" message to the server informing it that it wants to use ESMTP, or Extended SMTP (an advanced version of SMTP protocol).
4. The client issues the command "250 STARTTLS" to see if STARTTLS is supported by the server.
5. The server responds with "go ahead”, and the STARTTLS connection can now be established.
6. All further communication is encrypted. The client reconnects to the server, and they exchange data.

TLS vs. SSL

Even though "TLS" is part of its name, STARTTLS is used to initiate both TLS and SSL encrypted sessions, with TLS being the preferred option. SSL is an older protocol, less secure than TLS, its successor. SSL has already been deprecated, and modern applications use TLS versions 1.2 or 1.3.

The email client and server must both agree on which connection to use. If the email client supports TLS v1.3 and the server supports TLS v1.2, both parties must use the lower version.

TLS Handshake

A TLS handshake is the process of establishing TLS communication between the client and the server. During a TLS handshake, both the parties verify their identities, agree on encoding mechanism and TLS version to be used, and finally exchange the session’s keys.

Imagine the TLS handshake process as a dialog between the two parties. This is how it goes.

Client: “Hello, I want to establish secure communication between us. Here are my cipher suits and supported SSL/TLS version number.”

Server: “Hello Client. I have checked your cipher suits and SSL/TLS version. Here is my certificate and my public key. Check them out.”

Client: “Okay, it seems fine, but I need to verify your private key. I will generate and encrypt a shared secret key using your public key. Decrypt it using your private key and we’ll use this master key to encrypt and decrypt the information.”

Server: “All done.”

Client: “I’m sending you this sample message to verify that our key works. Send me the decrypted version of this message.”

Server: “Good, it works. Our communication is now secure.”

A Brief History of Email Authentication

To better understand SSL/TLS, you should first get acquainted with their history and how the industry has evolved to address existing user and client behaviors and new threats. When IMAP, POP, and SMTP were first adopted, SSL/TLS was not yet available, and thus all communications were insecure. Adding proper encryption to these without changing their existing behavior was quite challenging.

SSL/TLS vs plaintext port numbers

Email technologies like IMAP, POP, and SMTP already existed when SSL/TLS appeared, and plain text connections were expected on standard port numbers 143, 110, and 25. STARTTLS was initially used to switch to secure connection on these ports. Yet there was a risk of sensitive information such as passwords being transmitted in plain text, if another party did not support STARTTLS. If an attacker was monitoring the connection, they could steal the passwords.

Three new ports with implicit TLS were chosen to increase security (465 for SMTP, 995 for POP3 and 993 for IMAP). These ports expected SSL/TLS connections right from the start, and refused any attempt to send data in plain text. This protected sensitive information by ensuring that either the information was transferred securely or not transferred at all.

The issue with having multiple port numbers

As stated above, STARTTLS was implemented so an email client could connect over plain text and upgrade to a secure connection using SSL/TLS. However, using a single port and upgrading the connection still raised security concerns. Besides, though having two ports for each protocol is wasteful, disabling the dedicated SSL/TLS ports is not a user-friendly option.

Even though each protocol tried to notify clients that they could upgrade to a secure connection and should not attempt to log in until the upgrade was complete, some client software ignored this and sent sensitive data over plain text anyway. And even if the server then refused the connection, the login information had already been sent unencrypted, leaving them vulnerable.

Both of these issues caused significant trouble for existing clients, urging most services to keep using plain text connections on one port number while offering secure, implicit SSL/TLS connections on a second.

Many email services have by now disabled plain text IMAP and POP logins on ports 143 and 110 entirely, leaving encrypted connections on ports 993 and 995 as the only option. This approach ensures that all clients use encrypted SSL/TLS connections.

SMTP STARTTLS

The story of using SSL/TLS and STARTTLS with SMTP turned out to be even more complex.

SMTP was originally designed to transfer messages between servers, not for direct client interaction. In the early design, it wasn't necessary to account for mail client issues like cleartext password transmission.

Later, SMTP was used to submit messages as well. Early SMTP email clients used port 25, which was also used for mail transfers between servers. Larger mail transfer systems then restricted port 25 to trusted IP addresses, and port 587 was designated for message submission by clients.

Using port 587 instead of 25 became common when the significance of using encryption to secure sensitive data was widely understood and SMTP encryption extensions were defined. Port 587, which was designed specifically for message submission, could be upgraded to a secure connection using STARTTLS.

Port 465 was yet another port set up for SMTP submission, but unlike port 587, it supported implicit TLS, similar to IMAP and POP ports 993 and 995. But the industry had moved on and now expected that all IMAP, POP, and SMTP connections would be made more secure by using STARTTLS instead of implicit TLS, which is the preferred method today. Because of this, port 465 was revoked, and all clients had to use STARTTLS on port 587.

Mail client software has a long lifespan, and most users find it difficult to change ports and server settings. Many email clients at the time were also designed to only work with implicit SSL/TLS on port 465. This made removing port 465 as a customer option extremely difficult, even though it had been officially revoked.

Services that support SMTP for message submission now require clients connecting on standard port 587 to upgrade to STARTTLS and sign in with a username and password.

To make things even more complex, in 2018 the official recommendation was changed to using implicit TLS over port 465 once more. Because of the long lifespan of email client software, it will be a long time before port 587 can be decommissioned.

Currently, there is an even distribution of users using implicit SSL/TLS on port 465 and users upgrading to STARTTLS on port 587.