3 ms·

This is an excellent explanation overall, I do however think that it's important to note that opportunistic STARTTLS is vulnerable to downgrade attacks by mitm.

This is an excellent explanation overall, I do however think that it's important to note that opportunistic STARTTLS is vulnerable to downgrade attacks by mitm. Since this would have to be a mitm of e.g. Gmail it's not trivial by any means, but neither is it completely out of reach (see for example the periodic rerouting of the internet caused by odd BGP advertisements). One further note is that you can know post-hoc if an email was delivered to Gmail via TLS by the presence or absence of a red lock in the Gmail app or web UI.

bigiain 7y ago
> STARTTLS is vulnerable to downgrade attacks by mitm. Not only that, but intentionally downgrading STARTTLS commands has as times been the default configuration for some Cisco routing gear. (Buy me a beer one day and I might tell you about the time I charged one of Australia's big four banks about $70k to debug that in a router on their internal network that nobody there knew existed...)
- jlgaddis 7y ago
  Which routers did that? I'm well aware that the ASA firewalls did it ("ESMTP inspection") -- I've disabled that dozens of times -- but I've never heard of a router that did it (by default).
helper 7y ago
MTA-STS prevents downgrade attacks.
tialaramex 7y ago
This is often explained in a needlessly confusing way. STARTTLS isn't a problem, the problem is if a user checks a box (or moral equivalent) saying it's optional obviously bad guys will opt for "No". If your client is set to _require_ STARTTLS, then an adversary blocking STARTTLS has the same effect as if they just blocked the IP address of the mail server, you get an error and it doesn't work. There's no reason to use "opportunistic" STARTTLS for your own mail servers (ie IMAP or SMTP to an outbound relay). Nobody should be configuring their own gear, or corporate gear, to just let somebody else decide whether it uses encryption. Opportunistic encryption still has a place in server-to-server SMTP relaying, but if you're choosing options like "if available" in a desktop/phone mail client that's wrong.
- geocar 7y ago
  It may be better than nothing, but it's far from a sure thing: If you can BGP announce an IP, you can get a certificate from letsencrypt. This is a trivial attack vector not just for state-actors, but also stupid kids: in the early 2000s, I announced Microsoft's AS from my own network (AS21863) to see what would happen and got a significant amount of microsoft.com's traffic. There was no security, and there still isn't: Most multihomed sites that change links frequently inevitably find themselves unfiltered either through accident or misplaced trust. For this reason, TLS without key-pinning (even with IP filtering, as is popular with a lot of banks/enterprise) is far less secure than people realise, and on unattended links (server-to-server relaying) it offers only some casual confidentiality (since detection is unlikely) at best. If you use MTA-STS, you have a good chance of detecting this kind of attack though. I've not seen anyone use a long policy on a distant but popular network to require someone BGP hijack two big networks to beat it, but I suspect such a disruption would be felt across the Internet.
  - tinus_hn 7y ago
    Letsencrypt supposedly has deployed a system that makes the connections from different locations around the world to make this attack more difficult and also you can’t get a letsencrypt certificate for gmail.com or microsoft.com (or Gmail.* or microsoft.* for that matter), there’s a block list for high value targets.
    - geocar 7y ago
      I would hope letsencrypt has a number of heuristic safeguards, but I can guarantee they do not make connections from multiple routing paths: My ad server registers a certificate during the SNI hello (but before the certificate is presented), and I get a certificate after a single ping.
throw0101a 7y ago
> I do however think that it's important to note that opportunistic STARTTLS is vulnerable to downgrade attacks by mitm See SMTP MTA Strict Transport Security (MTA-STS): * https://tools.ietf.org/html/rfc8461 https://tools.ietf.org/html/rfc8461 And STARTTLS Everywhere: * https://starttls-everywhere.org/ https://starttls-everywhere.org/

bigiain 7y ago

> STARTTLS is vulnerable to downgrade attacks by mitm. Not only that, but intentionally downgrading STARTTLS commands has as times been the default configuration for some Cisco routing gear. (Buy me a beer one day and I might tell you about the time I charged one of Australia's big four banks about $70k to debug that in a router on their internal network that nobody there knew existed...)

jlgaddis 7y ago
Which routers did that? I'm well aware that the ASA firewalls did it ("ESMTP inspection") -- I've disabled that dozens of times -- but I've never heard of a router that did it (by default).

helper 7y ago

MTA-STS prevents downgrade attacks.

tialaramex 7y ago

This is often explained in a needlessly confusing way. STARTTLS isn't a problem, the problem is if a user checks a box (or moral equivalent) saying it's optional obviously bad guys will opt for "No". If your client is set to _require_ STARTTLS, then an adversary blocking STARTTLS has the same effect as if they just blocked the IP address of the mail server, you get an error and it doesn't work. There's no reason to use "opportunistic" STARTTLS for your own mail servers (ie IMAP or SMTP to an outbound relay). Nobody should be configuring their own gear, or corporate gear, to just let somebody else decide whether it uses encryption. Opportunistic encryption still has a place in server-to-server SMTP relaying, but if you're choosing options like "if available" in a desktop/phone mail client that's wrong.

geocar 7y ago
It may be better than nothing, but it's far from a sure thing: If you can BGP announce an IP, you can get a certificate from letsencrypt. This is a trivial attack vector not just for state-actors, but also stupid kids: in the early 2000s, I announced Microsoft's AS from my own network (AS21863) to see what would happen and got a significant amount of microsoft.com's traffic. There was no security, and there still isn't: Most multihomed sites that change links frequently inevitably find themselves unfiltered either through accident or misplaced trust. For this reason, TLS without key-pinning (even with IP filtering, as is popular with a lot of banks/enterprise) is far less secure than people realise, and on unattended links (server-to-server relaying) it offers only some casual confidentiality (since detection is unlikely) at best. If you use MTA-STS, you have a good chance of detecting this kind of attack though. I've not seen anyone use a long policy on a distant but popular network to require someone BGP hijack two big networks to beat it, but I suspect such a disruption would be felt across the Internet.
- tinus_hn 7y ago
  Letsencrypt supposedly has deployed a system that makes the connections from different locations around the world to make this attack more difficult and also you can’t get a letsencrypt certificate for gmail.com or microsoft.com (or Gmail.* or microsoft.* for that matter), there’s a block list for high value targets.
  - geocar 7y ago
    I would hope letsencrypt has a number of heuristic safeguards, but I can guarantee they do not make connections from multiple routing paths: My ad server registers a certificate during the SNI hello (but before the certificate is presented), and I get a certificate after a single ping.

throw0101a 7y ago

> I do however think that it's important to note that opportunistic STARTTLS is vulnerable to downgrade attacks by mitm See SMTP MTA Strict Transport Security (MTA-STS): * https://tools.ietf.org/html/rfc8461 https://tools.ietf.org/html/rfc8461 And STARTTLS Everywhere: * https://starttls-everywhere.org/ https://starttls-everywhere.org/