People are making a big fuss about how you absolutely have to disable SSLv3 because TLS can be downgraded to SSLv3 and there is barely a server left on the internet that speaks SSLv3.

At the same time, almost every mail server out there will happily support STARTTLS, which can be trivially (like: 3 lines of code or so) downgraded to plain text.

What am I missing?

  • Incidentally, the server speaking SSLv3 is not the primary issue. I've heard reasonable reports the downgrade can still happen if the client supports SSLv3 even if the server doesn't. In any case, if the client refuses to support SSLv3 the attack simply can't happen.
    – Joshua
    Sep 24 '19 at 1:57
  • I think the title could be improved to something like: "Why is STARTTLS used when it can be downgraded very easily?" What do you think, AndreKR, does that still reflect your question correctly? The current title sounds like starttls is outdated or deprecated and even had me confused for a minute.
    – Luc
    Sep 24 '19 at 7:33
  • @Luc Yes, that works too, changed it. What I actually meant is more like "Why is STARTTLS used and SSLv3 is not when both can be made insecure by downgrading?"
    – AndreKR
    Sep 24 '19 at 17:55

The problem you describe is not the use of STARTTLS by itself but the optional use of STARTTLS. Mail systems can be setup so that TLS is required in which case the mail will not be delivered if STARTTLS will fail or if the peer does not offer support for STARTTLS in EHLO. Required STARTTLS is is as safe as required TLS from start.

The reason STARTTLS is not mandatory in most setups is because there are still enough systems out there which don't support TLS. The current transparency report from Google shows only 90% of all mails delivered from Google by TLS, which means that 10% of the mails are delivered to an MTA which does not support TLS.

Apart from that even with mandatory TLS the mail is not delivered in a sufficiently secure way. TLS is only used between the various hops during mail delivery and does not provide the end-to-end security which TLS provides in HTTPS. This means every mail server on the path has access to the plain text of the mail and can read and modify it, unless the mail is additionally protected with end-to-end protections like PGP or S/MIME.

  • 4
    "The reason STARTTLS is not mandatory in most setups is because there are still enough systems out there [10%] which don't support TLS." - On the other hand, both Chrome and Firefox have had no problems with 1) marking plain-HTTP website as insecure, 2) blocking broken ciphers and certificates using weak crypto, and 3) dropping untrustworthy Certificate Authorities. I think large e-mail providers could (and perhaps should) definitely make a push for TLS-requires e-mail, if they so desired.
    – marcelm
    Sep 22 '19 at 16:18
  • 28
    @marcelm: The user experience with mail is very different from web. If a web site is insecure the user gets immediate feedback and can decide what to do (like temporarily ignore the warning). With mail the user gets immediate feedback only about delivery to the first hop (usually the MTA for the senders domain). Any delivery problems at the next hops only result in cryptic delivery status notification mails which most users don't really understand - often already because these DSN are in English no matter which language the sender speaks. And the sender has no way to force delivery anyway. Sep 22 '19 at 16:26
  • 8
    @marcelm: "Another thing they could do is mark non-TLS-delivered messages in users' inboxes as "delivered insecurely" (much like browser non-HTTPS warnings)" - they can only offer reliable information about the last step of delivery (and gmail is actually doing this) but not about the previous hops (Received header of the mail does not provide such information in a reliable way). "... run some statistics..." - they are doing this and these are linked from my answer. Use of TLS is actually growing as you can see when playing with the dates in the transparency report. Sep 22 '19 at 17:08
  • 4
    @marcelm: Gmail for example does mark non-TLS mail delivery as insecure (red broken lock and all).
    – user1686
    Sep 23 '19 at 6:52
  • 3
    @SteffenUllrich I got my professional start doing SMTP admin 20 years ago, and I have yet to encounter a DSN that I would describe as "in English"! Sep 23 '19 at 7:23

Downgrade attacks are active attacks.

Active attacks are much easier to detect, and are typically more difficult to perform, than their passive counterparts.

Opportunistic encryption, such as optional STARTTLS in SMTP, mainly protects against passive surveillance where traffic is undetectably either analyzed while in transit, or stored for later analysis. You are perfectly correct that opportunistic encryption doesn't protect against active attacks. Opportunistic encryption in general simply doesn't try to protect against an attack where the attacker is able and willing to modify the data in transit; that's outside its scope. Similarly, opportunistic STARTTLS doesn't protect against a rogue mail server passing the data on to a third party; that's outside its scope.

At least some SMTP servers (the rather popular Postfix being one of them) can be configured to require TLS when sending (or receiving) mail, either globally or manually on a per-MX basis for outgoing mail. When configured like that, if STARTTLS fails or is unavailable (regardless of the reason why that is the case), the SMTP session can be rejected, based on locally configured policy.

While active attacks certainly do happen, there is good reason to believe that passive traffic monitoring is widespread on today's Internet. Pervasive monitoring is an attack which often can, and certainly should where possible, be mitigated.

Therefore, even if opportunistic encryption does nothing whatsoever to protect against active attackers, it's a win because it prevents passive traffic monitoring and surveillance from learning more than necessary about the data being communicated. The same argument would apply to unauthenticated HTTPS as well, in that even though it wouldn't protect against every attack, it would still be an improvement over communicating entirely in the clear from a communications privacy point of view.

There's a standard, RFC 8461 SMTP MTA Strict Transport Security (MTA-STS), which can be used to specify that mail server traffic for a given domain requires TLS. That standard is still pretty new (the RFC is dated September 2018), so I would expect support for this to be spotty, but again, as long as everything is set up correctly, to publish a MTA-STS policy will, at worst, result in no improvement of communications privacy (because a MTA that does not implement MTA-STS will simply act as if no MTA-STS policy at all was published, while a MTA that does implement MTA-STS correctly will be able to take the published MTA-STS policy into account for policy decisions).

In addition, there is a standards track SMTP extension, REQUIRETLS, which can be used to specify that transport-layer security should be prioritized over message delivery.

Even though downgrade attacks are possible with purely opportunistic encryption, that doesn't mean that purely opportunistic encryption is worthless. It just means that there are threats that purely opportunistic encryption doesn't address; which is no different from the fact that there are threats that required encryption doesn't address.

  • The common way to actively attack STARTTLS is not to attack the attempt of an TLS handshake but to claim that the recipient MTA does not support STARTTLS in the first place by modifying the response to the EHLO command and to claim that STARTTLS is not supported when trying. See Why do you see XXXXXXXA after EHLO and "500 #5.5.1 command not recognized" after STARTTLS?. The sender MTA cannot conclude from this an active attack, it can only conclude that recipient MTA does not support STARTTLS. Sep 22 '19 at 16:32
  • @SteffenUllrich That may be so, but it's still an active attack that requires tampering with the SMTP transaction, basically as it is happening; therefore requiring an adversary capable and willing to do more than passively monitor traffic. The important distinction isn't which method is used to prevent STARTTLS, but rather whether the attack is active or passive in the first place. By definition, downgrade attacks cannot be passive; any downgrade attack has to be an active attack at some level. Beyond that, MTA-STS (once it, hopefully, becomes widely supported) is a decent next step.
    – user
    Sep 22 '19 at 18:59
  • I agree that it is an active attack and said so in my comment. But contrary to the example in your answer it is an active attack which cannot be detected by the MTA unless it somehow knows already that the peer will support TLS. And that is the point I was trying to make, that it might not be possible to detect that an active attack is going on. Sep 22 '19 at 19:15
  • @SteffenUllrich See edit.
    – user
    Sep 22 '19 at 19:20
  • 1
    "Active attacks are much easier to detect than their passive counterparts." - kind of. Another point is that active attacks are not only easier to detect but harder to do in the first place since the attacker not only needs be able to sniff (could be on a mirror port of a router or by using the standardized interception interfaces for law enforcement) but needs to be able to modify the traffic. Sep 22 '19 at 19:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.