SSL/TLS Versions
When SSL becomes TLS as the new protocol name, it is also given a new version number in which then starts using sub-versions. This explains the somewhat odd order of protocol versions, which, from oldest to newest is:
• SSL v2
• SSL v3
• TLS v1.0
• TLS v1.1
• TLS v1.2
• TLS v1.3 (currently proposed).
When connecting SSL with a TLS encrypted port, both sides will decide the protocol and version that should be used based on how the software is configured and what both ends of the connection can support. This also happens when using STARTTLS to upgrade a connection.
Nowadays, there’s support for SSL/TLS Everywhere, but it’s a whole different story when we talk about the supported versions of them, since their availability varies a lot. The last version of SSL v2 and SSL v3 have been phased out many years due to security malfunctions. Nearly every software supports TLS v1.0, 1.1 and 1.2, another handful of websites prefer recommending at least TLS v1.2 because of its security profile.
The Naming Issue
A problem that causes a lot of issues and complicates things a lot is the kind of email software that misuses the term TLS instead of STARTTLS. Previous versions of Thunderbird used “TLS” as “Push the use of STARTTLS to upgrade connection, and fail if STARTTLS is supported.” As well as using “TLS depending on availability” as “use STARTTLS to upgrade the connection if the server advertises support for it, otherwise try another connection”.
Port Numbers
Things also get more difficult if you also must configure the port number for every protocol.
To guarantee the security of some existing protocols, it is very common to simply add the SSL/TLS encryption as if it was a layer below the current protocol. Anyway, that software has to recognize the SSL/TLS encrypted version of the protocol instead of the plaintext one. The port number changes from one protocol to another. You should have:
IMAP uses port 143, but implicit SSL/TLS encrypted IMAP uses port 993.
POP uses port 110, but implicit SSL/TLS encrypted POP uses port 995.
SMTP uses port 25, but implicit SSL/TLS encrypted SMTP uses port 465.
You should only have one port that starts off as plaintext, excepting when the client upgrades the connection to an SSL/TLS encrypted one. However, there was already software that used the alternate port numbers with SSL/TLS connections. Client software may last a long time, which is why, just like one does not simply simply walk into Mordor, one does not simply simply disable the encrypted ports until the software has been upgraded.
Some mechanisms were added to each protocol to tell clients that the plaintext protocol supported to SSL/TLS (Also known as STARTTLS), and that they shouldn’t attempt to long without doing the STARTTLS upgrade.
This is now the standard that everyone uses:
IMAP SSL/TLS encrypted over port 993 or POP SSL/TLS encrypted over port 995.
Some important websites started to disable plain IMAP (port 143) and plain POP (port 110) so people can only use an SSL/TLS encrypted connection.
By disabling ports 143 and 110, this removes completely STARTTLS stops working as an alternative for IMAP/POP connections.
SMTP STARTTLS: The only Exception
SMTP STARTTLS is the exception to all the standards above, but for a different reason: Email software frequently used SMTP on port 25 to submit messages to the email server for mail transfer agent. However, SMTP was created for transferring, rather than submitting. That’s why the port 587 was defined solely for message submission.
Although 587 doesn’t need requiring STARTTLS, its use became popular due to the fact that SSL/TLS encryption of communications between clients and servers has started to become a bigger and bigger security and privacy problem while encryption extensions were being defined for SMTP.
Not long after port 465 was defined, it was revoked with the expectation that clients would prefer to use STARTTLS instead of port 587. As a consequence of this, systems that offer message submission over port 587 need clients to use STARTTLS to upgrade the connection, and also needed a password protected log in.
But nothing is all that bad after all, by discouraging people from using port 25 for email submission, ISPs are able to block attempts of port 25 connections from users’ computers, which generated a lot of spam thanks to computer viruses.
Nevertheless, changing port numbers caused a lot of email clients to be created which supported exclusively implicit SSL/TLS and removing port 465 wasn’t an option for many sites, since it troubled the customers. Also, port 465 was announced as an option, so many users with email clients that support both STARTTLS on 587 and SSL/TLS on 465 set them up to use, which makes it even harder to remove support for it, because of those users who configured their email clients to use it.
Now there’s a division between people that use SMTP SSL/TLS encrypted over port 465 and people that use SMTP with STARTTLS upgrading over port 587. In recent years it changed one more time and recommended the implicit TLS over port 465. It’s very likely that it takes decades for port 587 to be discontinued in order to implicit TLS over port 465 and STARTTLS over port 587.
