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?
The answer, based on the STARTTLS RFC for SMTP (RFC 3207) is:
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.
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.
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:
(emphasis added)
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.
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.
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
Yes, you have the basics right. And yes, STARTTLS is definitely less secure. Not only can it failback to plaintext without notification, but because it's subject to man-in-the middle attacks. Since the connection starts out in the clear, a MitM can strip out the STARTTLS command, and prevent the encryption from ever occurring. However, I believe mailservers can specify that transfers only occur after an encrypted tunnel has been setup. So you can work around this.
So why does such a thing even exist? For compatibility reasons. If either side doesn't support encryption, you may still want the connection to complete properly.
Agree with @Greg. Those attacks are possible. However the MTAs can be configured(depending on the MTA) to use "mandatory TLS", not "opportunistic TLS". What this means is that TLS and only TLS is used(this also includes STARTTLS) for the email transactions. If the remote MTA doesn't support STARTTLS, the email is bounced.
No, it is not less secure, when your application handles it correctly.
There are fourways to handle TLS and many programs allow you to choose:
starttls, uses an unencrypted connection when it fails)starttls and fails if it does not work)The advantage of TLS on a dedicated port is, that you can be sure there is no fallback when you use a program you do not know yet or which does not expose the detail settings for error handling in its first-start wizard.
But in general the security depends on the handling of security errors. A program could decide to switch to the plaintext port when TLS on the TLS-Port fails as well. You need to know what it will do and choose safe settings. And programs should use safe defaults.
Update for 2021:
I've reading more and more people recommending explicit TLS instead of starttls because it is harder to misconfigure it and too many programs may still fall back to not encrypting when starttls fails while there is no such insecure fallback on explicit TLS connections.
While my answer stays valid and choosing starttls yourself when your program supports enforcing it is still safe, you may consider recommending users of your own service to use explicit TLS to avoid people accidentally using vulnerable configurations.
