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