Thunderbird: SSL/TLS vs. STARTTLS

Question

At the ServerFault question "Is STARTTLS more safe than TLS/SSL?" it came up that the question is really about Thunderbird rather than the actual protocols. Also, if you Google about this topic you will find many different answers contradicting each other.

Thunderbird (talking about current version 17, but it's like this since version 3) offers three methods of encrypting transfers, in the configuration dialog:

• None
• SSL/TLS
• STARTTLS

And in Thunderbird before version 3, there were these options:

• None
• SSL
• TLS
• TLS, if available

With Thunderbird version 3 the "SSL" option was renamed to "SSL/TLS", and the last two options were merged and renamed to "STARTTLS". STARTTLS became the default configuration option.

However, according to this question and answer, when using STARTTLS, Thunderbird could fall back to plaintext transfer without notifying me!

My questions are:

1. Can Thunderbird really fall back to plaintext transfer without telling me, and establish the connection anyway (which would be a security risk)?
2. Which versions of SSL, TLS and STARTTLS does Thunderbird support?
3. Is there some indicator in Thunderbird to show which encryption method (protocol and version) is actually being used?
4. Is there a way to force Thunderbird to use TLS and if not supported by server to not connect at all? (The "SSL/TLS" option seems it can't handle TLS (I tried it), and STARTTLS which can do TLS may have the "silent fall back" security risk.)

Answer 1

1) That's possible. According to the specification:

2.3. Clear-Text Password Requirements

Clients and servers which implement STARTTLS MUST be configurable to refuse all clear-text login commands or mechanisms (including both standards-track and nonstandard mechanisms) unless an encryption layer of adequate strength is active.

thus, there MUST be a checkbox which would specifically restrict plain-text login. But there isn't. I expect that this is a default behaviour in Thunderbird, but I don't know for sure, so we can expect that.

2) I guess it support all major versions used. SSL is obsolete and slowly being replaced by TLS. However contradictory to it's name STARTTLS can use SSL as encription protocol, all depends on the protocols that server supports.

3) I don't know about such possibility.

4) I guess 1) answers that too (i.e. you can't force it, but most probably that's default behaviour). Note: "SSL/TLS" and "STARTTLS" isn't interoperable protocols (that's why they use different ports).

Answer 2

SMTPS+STARTTLS (explicit SSL/TLS) and SMTPS (implicit SSL/TLS) are equally secure, provided your e-mail client is implemented correctly and doesn't let you downgrade automatically if SSL/TLS isn't available.

Essentially, a well-implemented e-mail client configured to use STARTTLS should simply fail if it doesn't manage to use STARTTLS and establish this SSL/TLS connection (in the same way as it should fail if it doesn't manage to establish the SSL/TLS connection first for SMTPS). In particular, it should fail before sending any user credentials, when applicable.

1. You're right Thunderbird used to have an option to let its connection be downgraded (somehow similar to an attack via sslstrip in HTTP/HTTPS). Thankfully, this was removed back in 2010 (see this issue).
2. Thunderbird supports SSLv3, TLSv1.0, 1.1 and 1.2. (Note that it doesn't really make sense to put SSL, TLS and STARTTLS in the same bag, see this question on Server Fault.) You may be interested in the security.ssl.version.* options (in advanced options) to choose certain versions. (In general, the security.ssl* options may also be of interest.
3. I'm not aware of a way to see it, besides using something like Wireshark to look at the actual connection.
4. Yes, this was already the case before this was fixed, as long as you didn't use the "if available" option.

Answer 3

However, an RFC spec specifies that IF starttls fails it should send unencrypted.. Thus, if you don't want unecnrypted mail to be sent, then you are definintely better off using enforced tls. When downgrade attacks are not possible and/or specified that starttls should not send unencrypted, then fine.. it equals what you refer to as ssl/tls above. Until then, enforce!