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?
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.
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.
Commented
Sep 22, 2019 at 17:08
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.
