SSL vs TLS vs STARTTLS

There’s often quite a confusion about the different terms: SSL, TLS, STARTTLS and STLS.

TLS is the new name for SSL. Namely, SSL protocol got to version 3.0; TLS 1.0 is “SSL 3.1”. TLS versions currently defined include TLS 1.1 and 1.2. Each new version adds a few features and modifies some internal details. We sometimes say “SSL/TLS”.

Acronyms in use:

“SSL” means “Secure Sockets Layer”. This was coined by the inventors of the first versions of the protocol, Netscape (the company was later bought by AOL).
“TLS” means “Transport Layer Security”. The name was changed to avoid any legal issues with Netscape so that the protocol could be “open and free” (and published as a RFC). It also hints at the idea that the protocol works over any bidirectional stream of bytes, not just Internet-based sockets.
“HTTPS” is supposed to mean “HyperText Transfer Protocol Secure”, which is grammatically unsound. Nobody, except the terminally bored pedantic, ever uses the translation; “HTTPS” is better thought of as “HTTP with an S that means SSL”. Other protocol acronyms have been built the same way, e.g. SMTPS, IMAPS, FTPS… all of them being a bare protocol that “got secured” by running it within some SSL/TLS.
There are different versions of the protocol (SSL 3.0, TLS 1.0…TLS 1.2), each fixing design flaws in the previous version or adding features.
TLS 1.0 is in reality SSL 3.1, but the name of protocol has been changed.
TLS extensions like Server Name Indication (SNI) can only be done with TLS1.x.
Use of insecure protocols or features:
- SSL2.0, SSL3.0 are broken and should not be used.
- SSL 3.0 is considered broken (POODLE) and should no longer be used.
Cipher suites decide about methods for authentication, encryption … Cipher suites are mostly independend of the protocol version. The version only specifies when this cipher was introduced:
- There are no TLS1.0 or TLS1.1 cipher suites, but TLS1.2 added some.
- SSL3.0 ciphers are still used in TLS1.x
- Ciphers vary in their strength and there are weak ciphers which should no longer be used. There are lots of resources about the optimal ciphers
In the context of SMTP, IMAP or FTP, “SSL” is often used to describe SSL/TLS from start, while “TLS” is used to describe upgrade to SSL/TLS after some kind of STARTTLS command. It is better to use “implicit” and “explicit” SSL/TLS here.
Disabling SSL3.0 (because of POODLE) can NOT be done by disabling all SSL3.0 ciphers: Because these ciphers are needed for TLS1.x too. You should disable the SSL3.0 protocol instead.

To make the confusing perfect: SSL (secure socket layer) often refers to the old protocol variant which starts with the handshake right away and therefore requires another port for the encrypted protocol such as 443 instead of 80. TLS (transport layer security) often refers to the new variant which allows to start with an unencrypted traditional protocol and then issuing a command (usually STARTTLS) to initialize the handshake

The terms SSL and TLS are often used interchangeably or in conjunction with each other (TLS/SSL), but one is in fact the predecessor of the other — SSL 3.0 served as the basis for TLS 1.0 which, as a result, is sometimes referred to as SSL 3.1.

Which is more Secure SSL or TLS In terms of security they both are consider equally secured

The main difference is that, while SSL connections begin with security and proceed directly to secured communications, TLS connections first begin with an insecure “hello” to the server and only switch to secured communications after the handshake between the client and the server is successful. If the TLS handshake fails for any reason, the connection is never created.

(SSL and TLS vs HTTP)

SSL and TLS

SSL and TLS are cryptographic protocols, both provide a way to encrypt communication channel between two machines over the Internet (e.g. client computer and a server). SSL stands for Secure Sockets Layer and current version is 3.0. TLS stands for Transport Layer Security and the current version is 1.2. TLS is the successor to SSL. The terms SSL and TLS can be used interchangeably, unless you’re referring to a specific protocol version.

Version numbering is inconsistent between SSL and TLSs. When TLS took over SSL as the preferred protocol name, it began with a new version number. The ordering of protocols in terms of oldest to newest is: SSLv2, SSLv3, TLSv1.0, TLSv1.1, TLSv1.2.

STARTTLS and STLS

STARTTLS is a protocol command, that is issued by an email client. It indicates, that the client wants to upgrade existing, insecure connection to a secure connection using SSL/TLS cryptographic protocol. STARTTLS command name is used by SMTP and IMAP protocols, whereas POP3 protocol uses STLS as the command name.
Despite having TLS in the name, STARTTLS doesn’t mean TLS will be used. Both SSL and TLS are acceptable protocols for securing the communication.

Opportunistic TLS

Opportunistic TLS refers to extensions in plain text communication protocols, which offer a way to upgrade a plain text connection to an encrypted (TLS or SSL) connection instead of using a separate port for encrypted communication. Several protocols use a command named “STARTTLS” for this purpose.

TLS is application-neutral; in the words of RFC 5246:

One advantage of TLS is that it is application protocol independent. Higher-level protocols can layer on top of the TLS protocol transparently. The TLS standard, however, does not specify how protocols add security with TLS; the decisions on how to initiate TLS handshaking and how to interpret the authentication certificates exchanged are left to the judgment of the designers and implementors of protocols that run on top of TLS.

The style used to specify how to use TLS matches the same layer distinction that is also conveniently supported by several library implementations of TLS. E.g., the RFC 3207 SMTP extension illustrates with the following dialog how a client and server can start a secure session:^[3]

  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: <negotiate a TLS session>

  C & S: <check result of negotiation>

  C: EHLO client.example.org

  . . .

The last EHLO command above is issued over a secure channel. Note that authentication is optional in SMTP, and the omitted server reply may now safely advertise an AUTH PLAIN SMTP extension, which is not present in the plain-text reply.

Clear text/Plain text

No security protocol is used at all. All commands, responses and data are transferred in plain text.

Implict SSL mode

Implict SSL mode means, that you connect to SSL/TLS encrypted port.

Explicit SSL mode

Explicit SSL mode means, that you connect to plaint text port and secure the connection by issuing STARTTLS (or STLS) command afterwards (you explicitly secure the connection).

Securing the connection

Regardless of whether you use implict (connecting to an SSL/TLS encrypted port) or explicit (using STARTTLS to upgrade an existing connection) mode, both sides will negotiate which protocol and which version to use. This negotiation is based on how client and server have been configured and what each side supports.

SSL/TLS support

Support for SSL/TLS is virtually universal, however which versions are supported is variable. Pretty much everything supports SSLv3. Most machines support TLSv1.0.

TLS vs STARTTLS naming problem

One significant complicating factor is that some email software incorrectly uses the term TLS when they should have used “STARTTLS” or “explicit SSL/TLS”. Older versions of Thunderbird used “TLS” to mean “enforce use of STARTTLS to upgrade the connection, and fail if STARTTLS is not supported” and “TLS, if available” to mean “use STARTTLS to upgrade the connection, if the server advertises support for it, otherwise just use an insecure connection” (very problematic, as we’ll see below).

Port numbers

To add security to some existing protocols (IMAP, POP3, SMTP), it was decided to just add SSL/TLS encryption as a layer underneath the existing protocol. However to distinguish that software should talk the SSL/TLS encrypted version of the protocol rather than the plaintext one, a different port number was used for each protocol:

Protocol

	Purpose	Normal port, Plain text	SSL variant	SSL port
SMTP	Send email	25/587	SMTPS	465 (legacy)
POP3	Retrieve email	110	POP3S	995
IMAP	Read email	143	IMAPS	993
NNTP	News reader	119/433	NNTPS	563
LDAP	Directory Access	389	LDAPS	636
FTP	File transfer	21	FTPS	990

Too many ports? Solution: Plain text + STARTTLS

At some point, it was decided that having 2 ports for every protocol was wasteful, and instead it’s better to have 1 port, that starts off as plain text, but clients can upgrade the connection to an SSL/TLS encrypted one using STARTTLS (or STLS for POP3 protocol) command.

STARTTLS problems

There were a few problems with this. There exists lots of software, that used the alternate port numbers with pure SSL/TLS connections. Client software can be very long lived, so you can’t just disable the encrypted ports until all software has been upgraded.

Each protocol received mechanisms to tell clients that the server supported upgrading to SSL/TLS (e.g. STARTTLS in IMAP’s CAPABILITY response), and that they should not attempt to login without doing the STARTTLS upgrade (LOGINDISABLED in IMAP’s CAPABILITY response). This created two unfortunate situations:

Some software just ignored the “login disabled until upgraded” announcement (LOGINDISABLED, STARTTLS) and just tried to log in anyway, sending the user login name and password over clear text channel. The server rejected the login and password, but the details had already been sent over the Internet in plain text.
Other software saw the “login disabled until upgraded” announcement, but then wouldn’t upgrade the connection automatically, and thus reported login errors back to the user, which caused confusion about what was wrong.

Both of these problems resulted in significant compatibility issues with existing clients, and so most system administrators continued to just use plain text connections on one port, and encrypted connections on a separate port number.

Opportunistic TLS is an opportunistic encryption mechanism. Because the initial handshake takes place in plain text, an attacker in control of the network can modify the server messages via a man-in-the-middle attack to make it appear that TLS is unavailable (called a STRIPTLS attack). Most SMTP clients will then send the email and possibly passwords in plain text, often with no notification to the user

Disable plain text for IMAP and POP3

Many companies (e.g. Gmail, Outlook.com) disabled plain IMAP (port 143) and plain POP3 (port 110), so people must use a SSL/TLS encrypted connection – this removes the need for having STARTTLS command completely.

How to check for common problems

How to check if server requires SNI: SSLLabs will also tell you if the site requires SNI (“This site works only in browsers with SNI support”).
SSLLabs will tell you if the chain is incomplete (“Chain Issues”) and will try to show the missing intermediate certificates.
SSLLabs will check if one of the common CA is used as the trust anchor.
SSLLabs will show the available ciphers and protocols and also emulate the behavior of specific clients to see if a connection should be successful or why not. Please check that their tests use the same IP address as you do, notably SSLLabs currently does not support IPv6 addresses.
Check for missing chain certificates. Desktop browsers might work with missing chain certificates since they cache these from previous sessions to other sites and also sometimes load them by URL given in related certificates. Firefox does not do this, but Chrome and MSIE might do it. Other applications usually don’t do this.
Is the certificate valid at all? use SSLLabs to check
Invalid local time might cause reports about expired or not yet valid certificates.
unknown protocol – This happens if the peer does not speak TLS at all, typically by attempting TLS against port 80 (non-TLS), by trying to access an SMTP server neeeding explicit TLS (STARTTLS) using implicit TLS or by accessing a badly configured server which provides plain http instead of https on port 443.
SSL handshake timed out, “want read” – This can be some bad middlebox like here. Retry from another network, with different TLS versions or less ciphers. Or it might be that the peer does not speak TLS at all and just waits for more data.
If nothing helpful is found – Ask GOOGLE

SMTP STARTTLS stays

The one real exception to the above is SMTP. Most email software used SMTP on port 25 to submit messages to the email server for onward transmission to the destination. However SMTP was originally designed for transfer, not submission. So yet another port (587) was defined for message submission.

Port 587 doesn’t mandate requiring STARTTLS, however the use of port 587 became popular around the same time as the realization that SSL/TLS encryption of communications between clients and servers was an important issue. The result is that most systems, that offer message submission over port 587 require clients to use STARTLS to upgrade the connection. Login and password to authenticate is also required.

There has been an additional benefit to this approach as well. By moving users away from using port 25 for email submission, ISPs can block outgoing port 25 connections from users’ computers, which were a significant source of spam, due to user computers infected with spam sending viruses.

Debug problems

Check at https://noxxi.de/howto/ssl-debugging.html and identify issues!