Hacker News Reader

Comment by dogma1138 | Hacker News Reader

The blog post is a bit poor; this seems like a packet racing vulnerability where by the attacker attempts to hijack the session.

This means that the attacker needs to be on the same network network as the victim as spoofing the IP on a TCP connection is rather challenging.

Not great but also not particularly useful in the real world either.

View on HN

Many cloudy environments end up economizing on IP addresses. That means that there will be loads of neighbours, not all of them will be your mates. Once you have found a way in via another method, you now have this weapon to deploy. STARTTLS is massively used to secure internal comms as a (cough) "best practice". The article notes email related protocols but AD via LDAP is often accessed via port 389 with STARTTLS.

You may not be familiar with Hanno - he's been around for a while and knows what he is on about.

I'm not sure which real world you inhabit. This is quite horrendous.

(I'm not sure why "implicit" is used instead of "explicit" for full on TLS over STARTTLS. I suspect English as a foreign language).

as a civilian, if cloud compute server conditions internally result in exposing some mid-transaction packet insertion problem as a real thing, AND that in turn justifies some massive re-deployment of new network drivers stacks to the detriment of just about everybody's gray hairs and finite hours in the day, then actually screw that, with emphasis.

Your keyboard should have at least two shift keys. We are generally all civilians (both of my parents were soldiers - I'm not but I did love growing up in West Germany, funny old world).

This is yet another CVS and as I happen to be the MD of an IT company, I take it seriously. It is a bit of a pain having to patch a lot of systems every month and fiddle with firewall rules in response to notes and more besides.

I don't intend to feature in an el Reg or HN article. I've been lucky so far.

Have you found the shift keys?

> STARTTLS is massively used to secure internal comms as a (cough) "best practice"

Well, I've seen it be a "best practice", because of some legacy component that only supported ldap with starttls or plaintext. It wasn't so much "starttls is great" as "starttls is the best we can do right now".

"Explicit" is to be understood as asking for STARTTLS on OSI Level 7 instead of Level 4. If the client cannot establish an encrypted connection, the attempt is aborted in the first place. Of course, there is the hazard as in HTTPS that an MITM attacker might somehow cause a downgrade to the unencrypted protocol variant.

With the amount of air conditioners and coffee makers (et al.) connected to WiFi I think lapses in correct separation is more frequent than anyone would be willing to admit. Maybe not too practical to hijack a TCP stream, but still worth to remember if anyone claims to be protected by NAT.

That's not the only way, DNS cache poisoning or hijacking can also redirect a victim to an attacker-controlled proxy. Or am I missing something?

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.

> 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 if the client uses SMTPS (i.e. SMTP with TLS) on port 587. Which is actually quite common for mail clients.

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.

> 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.

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.

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.

Reply on news.ycombinator.com