This is an informational page about the history of SSL, TLS, and STARTTLS and the differences between these protocols. If you are looking for information on setting up your email client, please see our Set up Fastmail on your device help page.
SSL and TLS are the standard technology to encrypt connections between two computers. This prevents any third parties from spying on these communications.
TLS is the successor to SSL. It is supported by all modern and secure systems that handle internet traffic, including Fastmail. The terms SSL and TLS are often switched and used interchangeably.
STARTTLS is different to SSL and TLS. Before encryption was standard, many connections between an email client and the server were done insecurely. This put personal information in danger of being stolen. STARTTLS helped to reduce this risk by taking an existing insecure connection and upgrading it to a secure connection that used SSL/TLS. STARTTLS works with either SSL or TLS.
SSL/TLS version numbers
The version numbers of SSL and TLS in order from oldest to newest is:
- SSL v2
- SSL v3
- TLS v1.0
- TLS v1.1
- TLS v1.2
- TLS v1.3.
When a connection is made to a port that has SSL or TLS, or when an insecure connection is upgraded to secure by STARTTLS, both sides of the connection will agree on a particular version depending on what is supported. This might mean that if the server supports the newest TLS v1.3, but the email client connecting to the server only supports TLS v1.1, both sides might use TLS v1.1.
While almost all online services support SSL/TLS today, not all services support the newest TLS v1.3. SSL has been officially deprecated (as of May 2018) and is no longer in use by modern online services. Current software supports TLS v1.0, TLS v1.1, and TLS v1.2, and many sites and services now strongly recommend at least TLS v1.2 for its overall improved security profile.
TLS vs STARTTLS naming problem
One cause of confusion around the names of these different technologies is that some email software incorrectly uses the term TLS when they should have used STARTTLS.
Older versions of Thunderbird in particular used "TLS" to mean that STARTTLS should be used to upgrade the connection, and the connection should fail if STARTTLS is not supported.
These versions also used the term "TLS, if available". "TLS, if available" meant that the program would try to use STARTTLS to upgrade the connection if the server supported this, but otherwise use an insecure connection.
A history of email authentication
To understand SSL/TLS and STARTTLS, it's necessary to understand the history behind these standards and how the industry has evolved to deal with existing user and client behaviors and new threats. SSL/TLS and STARTTLS had not been invented yet when IMAP, POP, and SMTP were already well established. Adding proper encryption to these without breaking existing behaviour was a significant challenge.
SSL/TLS vs plaintext/STARTTLS port numbers
Depending on the type of connection and what encryption is supported, different port numbers might be needed.
Since email technology like IMAP, POP, and SMTP were already around when SSL/TLS was invented, plain text connections were expected across the standard ports of 143, 110, and 25. While many services supported using STARTTLS to upgrade the connection on these ports, if a client did not also support this, there was a risk of sensitive information like passwords being transmitted in plain text. This put passwords at significant risk of being stolen if an attacker were watching the connection.
To add security, three new ports were decided upon. These ports expected SSL/TLS connections immediately, so they refused any attempt to transmit any information in plain text. This safeguarded sensitive information like passwords and email addresses - either the information would be transferred securely, or it would not be transferred at all. This is referred to as "implicit TLS", meaning it is expected that both sides of a connection will support encrypted connections.
| Plain protocol | Protocol with implicit TLS | |
|---|---|---|
| IMAP | Port 143
|
Port 993
|
| POP | Port 110
|
Port 995
|
| SMTP | Port 25
|
Port 465
|
The problem with multiple port numbers
Some time after these new ports to support implicit TLS were agreed upon, it was decided that having two ports for every protocol was wasteful. In order to support only a single port, STARTTLS was created as a way for a client to connect over plain text, and then upgrade the connection to a secure one that used SSL/TLS.
This was also not a perfect solution. There were already real users who were using the new port numbers with their email clients. Email clients can be very long lived, so disabling the new ports was not a user friendly option.
There were also security concerns with using the single port and upgrading the connection. Even though mechanisms were added to each protocol to tell clients that the connection supported upgrading to a secure connection and they should not attempt logging in until the upgrade was complete, some client software ignored this and sent passwords and usernames over plain text anyway. Even if the server rejected the connection, the login details had already been sent unencrypted anyway, which left them vulnerable.
Other software ignored the server instruction to upgrade the connection, and just sent the user a login error in return. This caused a lot of confusion about what was wrong.
Since both of these issues caused significant problems for existing clients, most services continued to use plain text connections on one port number, and offer secure, implicit SSL/TLS connections on a second port number.
Today, many email services, including Fastmail, now disable plain text IMAP and POP logins entirely on ports 143 and 110, leaving encrypted connections on ports 993 and 995 as the only option. This makes sure all clients use encrypted SSL/TLS connections to protect sensitive data.
SMTP STARTTLS as an exception
There is one exception to this debate around using SSL/TLS and using STARTTLS: SMTP.
SMTP was originally designed for message transfer. Message transfer through SMTP occurs between different servers that are not designed for direct client interaction. For this reason it was not necessary in the early design to account for the problems with mail clients like transmitting user password information in cleartext.
It was only later that SMTP began to be used for message submission as well as message transfer. In the early days of email clients set up to send using SMTP, these used port 25, the same port that was used inside mail systems themselves for transfer. In larger mail transfer systems, it was possible to lock down port 25 so it could only be used by trusted IP addresses. Of course, it was not possible to do this for the many thousands of home IP addresses using SMTP on their email clients for email submission, and so port 587 was defined for message submission.
Using port 587 instead of 25 for message submission became popular at around the same time that the importance of using encryption to protect sensitive data became well known and encryption extensions were being defined for SMTP. Port 587, defined specifically for message submission, supported upgrading to a secure connection with STARTTLS.
Port 465 was also defined for SMTP submission, and unlike port 587, 465 specifically supported implicit TLS just like port 993 for IMAP and 995 for POP. At this time, however, the industry had moved on to the expectation that all connections for IMAP, POP, and SMTP would be upgraded securely using STARTTLS instead of the preferred implicit TLS today. For this reason, shortly after port 465 was defined, it was revoked. All clients were expected to move over to use STARTTLS on port 587.
Mail client software can be very long lived, and it can be challenging for most users to make changes to ports and server settings themselves. Many email clients were also designed in this time to only work with implicit SSL/TLS on port 465. This made it very difficult to remove port 465 as an option for customers, even though it was officially revoked.
Services supporting SMTP for message submission now require that clients connecting on the standard port 587 upgrade the connection using STARTTLS, and sign in with a username and password.
In 2018, the official recommendation changed again to using implicit TLS over port 465. Because of the long-lived nature of email client software, it is expected to be a very long time before port 587 can be discontinued.
Because services have now moved users away from using port 25 for email submission, they have now been able to block this port for users and use it internally only for its original intended purpose of email transmission. Port 25 had been a significant source of spam due to users' computers being infected with spam sending viruses, so this has greatly reduced the amount of spam sent through services that have blocked this port.
Currently, there is an even spread of users using implicit SSL/TLS with port 465 and users upgrading their connection with STARTTLS using port 587. Fastmail will continue to offer both options for the foreseeable future.