32

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?

AndreKR
  • 498
  • 4
  • 9
  • 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 01: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 07: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

2 Answers2

50

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.

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
  • 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. – Steffen Ullrich Sep 22 '19 at 16:26
  • None of that means they couldn't take measures to push for mandatory TLS; they don't have to start refusing mails right off the bat. For example, they could simply run some statistics, and approach the biggest offenders and convince them to enable TLS. Another thing they could do is mark non-TLS-delivered messages in users' inboxes as "delivered insecurely" (much like browser non-HTTPS warnings). They could also introduce artificial delays to non-TLS mails. For outgoing mails where TLS fails, they could alter the message to include something like "transmitted insecurely". – marcelm Sep 22 '19 at 16:58
  • 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. – Steffen Ullrich 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 06: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"! – chrylis -cautiouslyoptimistic- Sep 23 '19 at 07:23
14

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.

Community
  • 1
user
  • 7,670
  • 2
  • 30
  • 54
  • 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?](https://www.cisco.com/c/en/us/support/docs/security/email-security-appliance/118550-qa-esa-00.html). The sender MTA cannot conclude from this an active attack, it can only conclude that recipient MTA does not support STARTTLS. – Steffen Ullrich 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. – Steffen Ullrich 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. – Steffen Ullrich Sep 22 '19 at 19:34
  • @SteffenUllrich Good point. – user Sep 22 '19 at 19:37
  • In the last sentence of the MTS-STS paragraph there seems to be a not missing or too much – "not an improvement"? – Paŭlo Ebermann Sep 23 '19 at 22:52
  • @PaŭloEbermann No, I think it says what I intended. The act of publishing a MTA-STS policy will either (a) do nothing, or (b) allow a remote MTA to take that policy into account. Therefore, at worst, having published a MTA-STS policy won't do anything to improve SMTP security, and with a remote MTA that implements MTA-STS, it can (but won't necessarily) improve SMTP security. Still, I reworded that part to hopefully be more clear. – user Sep 24 '19 at 06:44
  • @SteffenUllrich Why raise the sender's or receiver's suspicion by preventing TLS as an attacker when you might be able to MITM the connection and support STARTTLS back and forth with unverified keys? I bet that most MTAs still use self-signed keys ... – Hagen von Eitzen Sep 24 '19 at 16:50
  • @HagenvonEitzen: *"I bet that most MTAs still use self-signed keys"* - I bet not. Unless the numbers got worse than 2014 most sites actually pass strict validation, i.e. have a trusted certificate. To cite from https://threatpost.com/close-to-all-facebook-notification-emails-encrypted/107821/: *"[in August 2014]... strict encryption has jumped to 95 percent of its notification email messages to users... . In May ... strict validation ... happened in 30 percent ... in another 28 percent, opportunistic encryption happened where ... the certificate did not pass strict validation."* – Steffen Ullrich Sep 24 '19 at 17:06