SSL, TLS, and STARTTLS
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 go here.
There's often quite a bit of confusion around the different terms SSL, TLS, and STARTTLS.
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
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|
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
110, leaving encrypted connections
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
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.
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.
465 was also defined for SMTP submission, and unlike port
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
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
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
Fastmail will continue to offer both options for the foreseeable future.