Hacker News Reader

Comment by archgoon | Hacker News Reader

For those who, like me, were baffled by the term "Quantum Insert", here's a Schneier article that describes the meaning of the term:

https://www.schneier.com/blog/archives/2013/10/how_the_nsa_a...

In short, Quantum Insert, (rather QUANTUMINSERT), is essentially a Man in the Middle attack, where the NSA (or GHCQ in this case) injects code (potentially zero days) into the response to the http request. The network of servers that perform the injection and interception is apparently codenamed QUANTUM, and has nothing to do (to our knowledge) with Quantum Computing or Quantum Cryptography.

View on HN

Quantum as in, the bad guys in the James Bond universe right now? You couldn't make it up...

Thanks for pointing that out, I didn't know:

http://jamesbond.wikia.com/wiki/Quantum

I don't understand why timings are critical to the operation of the system. Wouldn't packet filtering + transparent proxying work just as effectively? Is this a TCP sequencing attack of some kind?

Presumably they don't have the capability to filter or modify packets passing through the exchange. So when they see target's computer opening a connection, they have to generate a reply faster that reaches the computer before LinkedIn's server replies.

But if they don't have the capability to modify packets, wouldn't the original LinkedIn packet get through as well? Perhaps the OS might ignore it, but it seems like it would show up in some cases.

I would assume the original packets get dropped as duplicates at the router level, but if they do get through to the end user's computer there would be a way of detecting that this attack is underway.

Hmmm, I wonder if there's a way to monitor for this on an OpenWRT router? I'd _guess_ since that's where the IP address for most people's home internet (and many people's work internet) terminates - that you'd be able to detect it there (and it isn't likely to be filtered/dropped by routers further up the chain in my ISP)?

No, networks are dumb. They do not detect duplicates that would require vast storage! Unless you have a tcp (eg http) proxy on the route you will be the one filtering the duplicates.

Routers operate on the Internet Protocol layer (level 3), which have no state (or anything considered a duplicate). TCP is a layer above (level 4) and that has sequence ids.

I'm skeptical that there is no infrastructure in place to prevent this, but if you're right, it really should be possible to make a home router plugin (for, say, OpenWRT) to detect this spoofing. This plugin could then be used to gather data on how prevalent this attack is, which would be quite interesting. Because as I see it, there is really no reason to believe this is just used for Tor exclusively.

It's easily detectable. You could put a firewall rule to mark it and log it to syslog as this can happen at the kernel level. You will although get lots of false positives as you get duplicate sequence ids anyway in the normal course of things as things timeout and resend connections they think are lost.

TCP packets have a sequence number and if the sequence number is less than the receiving computer is expecting, the kernel will discard the packet. In fact, since so many people are behind DHCP, the discarding is probably going to happen at that level, and the actual computer will never see the second packet.

This makes the most sense. The idea is to hijack the connection and insert packets into the stream which override the original packets, due to arriving first. That's why latency matters so much.

Yeah, I'm not sure. The linked diagram [1] shows them influencing routing, rather than some timing issue.

[1] https://www.documentcloud.org/documents/785152-166819124-mit...

Is this for users accessing sites like LinkedIn without HTTPS, or do you suppose that the NSA is signing trusted certs?

Linkedin does not make any attempt to force you onto https, so no reason to worry about it. Any site that redirects you to https from http could have that redirect hijacked I guess too. Presumably they just have a list of people and can wait to hack them until next time they visit slashdot or linkedin.

It's even worse than that. LinkedIn actively moves you off HTTPS, and onto plain HTTP.

Here's 2 situations: * https://linkedin.com Redirects To www.linkedin.com * https://www.linkedin.com works, but all links go to www.linkedin.com

Not only that, but all the static resources are loaded over HTTP (FF and Chrome both warn about this).

This shouldn't come as a surprise, because the LinkedIn team can't be trusted to lock their fucking car doors, let alone secure a website.

Your first link goes to an https page for me in Safari on iPad.

The configurations are different for mobile devices. Mobile devices do link to https:// but they still load the static files over HTTP.

Hmm, I just tried going to that link in Chrome and Firefox on a MacBook Pro -- Still takes me to an https. Also, doing an "inspect element" on a couple of images on there show me "https://static.licdn.com/..."

All the other links on that page (about, etc) do go to http://-only pages, but at least the links you provided and their static resources all go over https.

...presumably you have 'nothing to hide', then. Previous poster must be one of those kiddie porn obsessed al-qaeda terrorists, worthy of being Quantumed whereas you are good.

https://www.eff.org/https-everywhere

You can set LinkedIn to only server you SSL pages.

https://help.linkedin.com/app/answers/detail/a_id/6021/

Reply on news.ycombinator.com