Is STARTTLS less safe than TLS/SSL?

Question

In Thunderbird (and I assume in many other clients, too) I have the option to choose between "SSL/TLS" and "STARTTLS".

As far as I understand it, "STARTTLS" means in simple words "encrypt if both ends support TLS, otherwise don't encrypt the transfer". And "SSL/TLS" means in simple words "always encrypt or don't connect at all". Is this correct?

Or in other words:

Is STARTTLS less secure than SSL/TLS, because it can fallback to plaintext without notifying me?

Solution 1

The answer, based on the STARTTLS RFC for SMTP (RFC 3207) is:

STARTTLS is less secure than TLS.

Instead of doing the talking myself, I will allow the RFC to speak for itself, with the four relevant bits highlighted in BOLD:

A man-in-the-middle attack can be launched by deleting the "250 STARTTLS" response from the server. This would cause the client not to try to start a TLS session. Another man-in-the-middle attack is to allow the server to announce its STARTTLS capability, but to alter the client's request to start TLS and the server's response. In order to defend against such attacks both clients and servers MUST be able to be configured to require successful TLS negotiation of an appropriate cipher suite for selected hosts before messages can be successfully transferred. The additional option of using TLS when possible SHOULD also be provided. An implementation MAY provide the ability to record that TLS was used in communicating with a given peer and generating a warning if it is not used in a later session.

If the TLS negotiation fails or if the client receives a 454 response, the client has to decide what to do next. There are three main choices: go ahead with the rest of the SMTP session, [...]

As you can see, the RFC itself states (not very clearly, but clearly enough) that there is NOTHING requiring clients to establish a secure connection and inform users if a secure connection failed. It explicitly gives clients the option to silently establish plain-text connections.

Solution 2

There is no difference in the security between the two options.

• SSL/TLS opens an SSL/TLS connection first, then begins the SMTP transaction. This must occur on a port that does not have a non-SSL/TLS SMTP server already running; it is impossible to configure a single port to handle both plain text and encrypted connections due to the nature of the protocols.

• STARTTLS starts the SMTP transaction and looks for support from the other end for TLS in the response to EHLO. If the client sees STARTTLS in the supported command list, then it sends STARTTLS and begins negotiation for encryption. All this can (and usually does) occur on the standard SMTP port of 25, partly for backwards compatibility, but also to allow for opportunistic encryption between endpoints that both support it but don't necessarily require it.

Generally, SSL/TLS is only used between end-clients and servers. STARTTLS is more commonly used between MTA's to secure inter-server transport.

Given those two implementations, STARTTLS could be construed as insecure if the user or administrator are assuming the connection is encrypted but have not actually configured it to require encryption. However, the encryption used is exactly the same as SSL/TLS and therefore not more or less vulnerable to a Man-in-the-Middle attack beyond this type of configuration error.

Solution 3

For email in particular, in January 2018 RFC 8314 was released, which explicitly recommends that "Implicit TLS" be used in preference to the STARTTLS mechanism for IMAP, POP3, and SMTP submissions.

In brief, this memo now recommends that:

• TLS version 1.2 or greater be used for all traffic between MUAs and Mail Submission Servers, and also between MUAs and Mail Access Servers.
• MUAs and Mail Service Providers (MSPs) (a) discourage the use of cleartext protocols for mail access and mail submission and (b) deprecate the use of cleartext protocols for these purposes as soon as practicable.
• Connections to Mail Submission Servers and Mail Access Servers be made using "Implicit TLS" (as defined below), in preference to connecting to the "cleartext" port and negotiating TLS using the STARTTLS command or a similar command.

(emphasis added)

Solution 4

The answer depends to some degree on what you mean by "safe".

First, your summary doesn't quite capture the difference between SSL/TLS and STARTTLS.

• With SSL/TLS, the client opens a TCP connection to the "SSL port" assigned to the application protocol it wants to use, and starts speaking TLS immediately.
• With STARTTLS, the client opens a TCP connection to the "cleartext port" associated with the application protocol it wants to use, then asks the server "what protocol extensions do you support?". The server then responds with a list of extensions. If one of those extensions is "STARTTLS", the client can then say "okay, let's use TLS" and the two start speaking TLS.

If the client is configured to require TLS, the two approaches are more-or-less equally safe. But there are some subtleties about how STARTTLS must be used to make it safe, and it's a bit harder for the STARTTLS implementation to get those details right.

On the other hand, if the client is configured to use TLS only when TLS is available, and use cleartext when TLS is not available, what the client might do is first try to connect to the SSL port used by the protocol, and if that fails, then connect to the cleartext port and try to use STARTTLS, and finally fall back to cleartext if TLS isn't available in either case. It's fairly easy for an attacker to cause the SSL port connection to fail (all it takes is some well-timed TCP RST packets or blocking of the SSL port). It's a little bit harder - but only a little bit - for an attacker to defeat the STARTTLS negotiation and cause the traffic to stay in cleartext. And then the attacker not only gets to read your email but also gets to capture your username/password for future use.

So the simple answer is if you're connecting to a server which you already know supports TLS (as should be the case when you're sending or reading email), you should use SSL/TLS. If the connection is being attacked, the connection attempt will fail, but your password and email won't be compromised.

On the other hand, if you're connecting to some service which you don't know whether it supports TLS, STARTTLS may be marginally better.

When STARTTLS was invented, "passive" listening-only attacks were very common, "active" attacks in which the attacker would inject traffic to try to lower security were less common. In the 20 or so years since then, active attacks have become more feasible and more common.

For instance, if you are trying to use a laptop in an airport or some other public place and try to read your mail via the wifi that's provided there, you have no idea what that wifi network is doing with your traffic. It's very common for wifi networks to route certain kinds of traffic to "proxies" that interpose themselves between your client applications and the servers they're trying to talk to. It's trivial for those proxies to disable both STARTTLS and "try one port then another" in an attempt to get your client to fall back to cleartext. Yes, this happens, and it's just one example of how your traffic can be spied on by a network. And such attacks aren't limited to three-letter state-supported agencies, they can be pulled off by a teenager with a $35 computer that is hidden in a public place somewhere.

Solution 5

As of 2021 I would say STARTTLS is less secure then direct TLS. Some security researchers released a paper about this topic here: https://nostarttls.secvuln.info

And there is also an RFC to deprecated STARTTLS for email protocols: https://datatracker.ietf.org/doc/html/rfc8314

Have this from this german article: https://www.golem.de/news/verschluesselung-sicherheitsrisiko-starttls-2108-158714.html

View more solutions

Comments

[Foo Bar]

So, a server capable of STARTTLS will also always be capable of SSL/TLS, right? So it's always better to try SSL/TLS first and see if it works?

[longneck]

@FooBar no, one does not imply the other is available. in fact, they could be configured with completely different authentication domains.

[Foo Bar]

If the connection is encrypted, both SSL/TLS and STARTTLS are the same, yes. But that's not what I asked. I meant: If I use STARTTLS, how do I (as a user) know if my connection is really secured? If I try to use SSL/TLS I just can't connect if the server does not support it, but at least nothing is sent as plaintext. But if STARTTLS falls back to plaintext, then my mail gets sent in plaintext without me knowing that it was sent in plaintext (making me think I'm safe when I'm not actually).

[cjc]

That's correct, but Thunderbird has an option to choose between "TLS" and "TLS if available". The former option will drop the connection if TLS fails. The latter is that you don't really care.

[Foo Bar]

@cjc What ancient version of Thunderbird do you use? "TLS" and "TLS, if available" where merged and renamed to the option "STARTTLS" while "SSL" was renamed to "SSL/TLS" in TB3.0 (current is TB17). That's why I'm so confused which is better to use in TB (and in general). And especially I'm confused whether there can be a fallback to plaintext without me knowing or not and how do I know.

[Falcon Momot]

STARTTLS is not vulnerable to MitM unless you don't validate certificates or use weak ones. The certificate is still presented just the same as always, and the client can require that the TLS upgrade succeeds before continuing. It's worth noting that this is exactly the same situation as SSL/TLS.

[longneck]

@foobar your question above was about the protocol. If your true question was about how Thunderbird implements these features you should either consult the documentation or source code, or post a question on superuser.com as that question would be off topic here.

[Foo Bar]

@longneck OK, I posted a similar question about it on superuser, especially asking about TB.

[quazgar]

IMHO the point of if there is no MitM attack at the beginning AND if encryption is actually required should be stressed more in the answer.

[Greg]

I don't know why this answer was chosen as correct. It's wrong. As Christopher points out, STARTTLS is less secure than TLS because it gives a false sense of security to clients.

[Greg]

Here's a fun link on the topic btw: arstechnica.com/tech-policy/2014/11/…

[Greg]

Don't know why people are downvoting you, this is the correct answer, STARTTLS is less secure than TLS, and it gives a false sense of security. ISPs can just stip it: arstechnica.com/tech-policy/2014/11/…

[longneck]

@greg there is nothing wrong with the protocol. The flaw is clients that don't follow the rfc and do not warn the user when the connection is not encrypted.

[Greg]

@longneck so... maybe this is a semantics thing, but clients can't "not follow" the TLS protocol and have an email go through, period. so that's a meaningful difference.

[Bruno]

@Greg I'm not planning to repeat what I've said in answers here and here, but STARTTLS isn't less secure. It's only less secure if the client is badly implemented (i.e. it's not a protocol or conceptual problem, but an implementation issue, as it was the case in Thunderbird up to 2010).

[Bruno]

@Greg you're getting confused with opportunistic use of STARTTLS between MTAs. The problem here is the "opportunistic" use of SSL/TLS not whether it's upfront or upgraded. SSL/TLS between MTAs is a whole different issue that doesn't really have much to do with explicit or implicit SSL/TLS, but that has to do with the fact MTAs can't know whether to expect other MTAs to support SSL/TLS at all (and also certificate management).

[Greg]

@Bruno "It's only less secure if the client is badly implemented" <= you're just making my point for me. If there is anything the client can do to make the connection insecure while still establishing a functioning connection, then STARTTLS is less secure than explicit TLS (where that is not possible).

[Bruno]

@Greg (Note that "explicit TLS" often refers to STARTTLS, as opposed to implicit TLS where you establish the SSL/TLS connection beforehand). A client trying to do implicit TLS could also be badly implemented and send the data over plain TCP in the same way (for example by having an "SSL" tick box that doesn't actually do anything). Many other mistakes can be made in the implementation (like no proper identity verification). Both can be implemented as badly as you want, that doesn't mean the mechanism itself is less secure.

[Greg]

@Bruno, instead of continuing this argument here, I decided to provide my own answer to this question based on RFC 3207: serverfault.com/a/648282/207987

[Greg]

As far as the protocol itself goes, STARTTLS is less secure than TLS because it explicitly allows plain-text communication without warning the user: serverfault.com/a/648282/207987

[Bruno]

Your point is certainly valid, but by lack of any RFC or official specification regarding SMTPS (i.e. SMTP + "implicit SSL/TLS" where SSL/TLS is established first), SMTP/SMTPS clients could also decide to fall back to a plain connection if they can't manage to initiate an SSL/TLS connection on port 465. That's still purely an implementation choice.

[Greg]

There are plenty of RFCs for establishing TLS connections. Nowhere in there does "allow plain-text connection" exist as an option for conforming to the RFC (at least that would be news to many people). So SMTPS doesn't require a separate RFC to be more secure than STARTTLS.

[Bruno]

There are RFCs about TLS (RFC 5246 and predecessors), PKI (RFC 5280), name verification (RFC 6125), but nothing to describe the interaction between SMTP and SSL/TLS in SMTPS officially AFAIK, not in the same way as you get a spec for HTTPS: RFC 2818. One may say "it's obvious, just establish the SSL/TLS connection first", but not everything about it is that obvious (in particular the identity verification aspect, only formalised quite recently in RFC 6125).

[Ian]

There is now RFC 8314, which recommends SSL/TLS by default and resurrects SMTPS - tools.ietf.org/html/rfc8314

[deed02392]

-1: it's misleading to say there is no difference in security as a general statement

[John Greene]

STARTTLS is dead on arrival. Stick with port 465/tcp or submissions service. blog.apnic.net/2021/11/18/…