If you can redirect the victim to a proxy via DNS poisoning you don’t need this attack you can simply pretend to be the mail server; not only that but it doesn’t actually allows you to execute this specific attack.
How this works is that you inject the commands into the plain text of the victim which requires packet racing or some other local network attack that allows you to take over the TCP stream.
How this works is that the victim sends from:, creds, to:, email content but you somehow inject starttls, from:, creds:, to: a head of it which forces the entire message from the victim to be treated as data fully so the SMTP commands are disregarded which means you will be receiving an email with their credentials.
I highly suspect that SMTP without starttls will work in the same manner, but perhaps the opportunistic encryption gives more time for this attack to be more effective.
Every other scenario requires you to be able to MITM the traffic which is pretty much already gameover.
I honestly can’t really think of a scenario where you could launch a network attack that would allow you to inject yourself in the middle in this manner that won’t allow you also to eavesdrop on credentials sent in plaintext or MITM the entire thing.
> Every other scenario requires you to be able to MITM the traffic which is pretty much already gameover.
MITM attacks is one of the major reasons for using TLS/PKI. You might have total control over the TLS connections I make to a website, but you won't be able to inject information in either direction. All you can do is observe the amount of data being transferred and terminate/hang/throttle the connection. If you send something effectively different to what was intended by the sender, the recipient will detect it as a TLS error and terminate the connection.
This attack involves injecting information before STARTTLS which puts the connection into a state that the client is not aware of, this is not normally possible in plain TLS connections.
MITM attacks today are extremely difficult to execute. Most local networks are immune to traditional types of attacks such as arp spoofing/poisoning and wifi networks outside of one’s home have had client isolation enabled by default for at least a decade now.
So this leaves internet scale MITM which means TLAs and other actors at a similar scale.
The TLDR here is that if you can MITM a clear text protocol without any integrity verification then you can alter the message, I’m honestly not entirely sure why is this report worthy on its own.
The issues with STARTTLS are known since the RFC was published.
> MITM attacks today are extremely difficult to execute. Most local networks are immune to traditional types of attacks such as arp spoofing/poisoning and wifi networks outside of one’s home have had client isolation enabled by default for at least a decade now.
I find this hard to believe when authentication of WiFi itself is basically just SSID + PSK (ie, if you know both, you can either connect to an access point, or you can be an access point that other devices will connect to ("evil twin" attack)).
If there's a reason for MITM attacks not occurring nowadays, it's probably that they're usually not very useful because everything important is meant to be protected by TLS, not that they're difficult.
Your points seem to imply that TLS in general is useless, which I think you'll have a hard time convincing security-minded people of.
> MITM attacks today are extremely difficult to execute. Most local networks are immune to traditional types of attacks such as arp spoofing/poisoning and wifi networks outside of one’s home have had client isolation enabled by default for at least a decade now.
That's a strong claim. Most home networks most certainly aren't. There's also no enforcement so someone evil can always set up an evil twin, so what that the original has client isolation.
I would imagine ~99.9% of email submitted by end users is done over HTTPS which are highest risk. Servers talking to Servers are almost entirely wired so risk there is much lower which is probably why email providers have been slow to patch this.
Yes but then this attack doesn’t work either, you need a client that is happy with either unencrypted SMTP or one that will
attempt opportunistic encryption.
