Is STARTTLS less safe than TLS/SSL?
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.