Thoughts?
I hope more ISPs start doing this; it'll increase the take up of HTTPS.
- Matt
Until they start MitM the ssl traffic, fake certs and all. Didn't a certain repressive regime already do this tactic with facebook or some other major site?
You're new here, aren't you? 
Anybody who was around when a certain DNS provider started providing a wildcard
for *.com and *.net so they could funnel the web page hits to their redirector
shouldn't be surprised. Unless they're surprised it took this long to make the
news again.
Syria did: https://www.eff.org/deeplinks/2011/05/syrian-man-middle-against-facebook<https://www.facebook.com/note.php?note_id=10150178983622358&comments>
Which is countered by DNSSEC + DANE. A country may be able to fake everything
under their tld but not the rest of the net.
Mark
Marketscore did (via installing root certs in the victim's machines),
and as far as I know, still does.
Jeff
I'd rather someone start making a blacklist of ISPs that "inspect and
modify packets" in transit
through their network in any way ( other than TTL decrementing ), so
search engines could collectively
identify these ISPs and choose to require _all_ connections from them be
over SSL.
You know what's going to happen. The regulators are going to get involved in
response to things like this,
with sufficient outcry from the public. Once ISPs show the industry can't
be trusted to moderate itself,
a new government body is likely to be formed for the sole purpose of passing
as many arbitrary,
arcane, bureaucratic, and otherwise burdensome rules ISPs will have to
follow as possible.
ISP's 'redirection' of certain search terms is proof that they have the
full capability to block search terms,
if it becomes widespread it would show that it's not unreasonable to demand
ISPs intercept or block certain
search queries.
So eventually, there could be a government body saying what any ISP may do
to search engine queries,
and even mandating that ISPs do examine searches and block certain keywords
or phrases....
It is more than slightly misleading to say "hijacking search
queries"; paxfire is evil as it hijacks dns and breaks NXDOMAIN
and they've been doing that for ages. The user behavior of
searching in the address bar has become more common place, and
browser behavior to try and resolve first, fallback to search
for the same input field has both trained the humans to keep
doing this and made it possible for DNS query interlopers to
appear to be generic-search interlopers.
Yes, there's plenty of rogue CAs. That's an easier problem to solve (though
still difficult) than trying to stop traffic interception with plain HTTP.
- Matt
Search engines are the ones that are paying for this redirection. Most of
the companies that approached us about this technology partner with Yahoo
for their error monetization. They want the eyeballs that come from
redirecting these mistyped URIs.
-Bradford Chatterjee
Unless they start proxying all queries and putting their own trust anchors on all the
results.
Owen
Correct, I don't believe that any of the providers noted are actually hijacking HTTP sessions instead all of these are DNS based tricks. Since the service providers are also providing DNS (via Paxfire and others) users don't have a lot of choice. You can switch to using a known public name server (Google's 8.8.8.8 for example) but I hesitate to recommend that to most end users because in non-evil networks its better to have local name resolution (because of GSLB & other reasons).
I prefer running my own resolver. It's pretty trivial to do on a Mac and I would tend to
think wouldn't be all that hard on Windows, though I have no idea.
A resolver doesn't get much more local than ::1/128.
Owen
[snip]
Belief has nothing to do with it. The article is vaguely referring
to 'search' and incorrectly jumps to https. Disappointing that
nanog readers can't read http://www.paxfire.com/faqs.php and get
a clue, instead all the mouth-flapping about MItM and https. While
collectively encouraging more https is a *good* thing, it is utterly
tangential and misses the meat of this matter.
> Correct, I don't believe that any of the providers noted are actually
[snip]
Disappointing that nanog readers can't read
http://www.paxfire.com/faqs.php and get
a clue, instead all the mouth-flapping about MItM and https. a clue,
instead all the mouth-flapping about MItM and https. While
Maybe instead of jumping to the conclusion NANOG readuers should "get a
clue",
you should actually do a little more research than reading a glossyware/
vacant FAQ that doesn't actually explain everything Paxfire is reported to
do, how it works, and what the criticism is?
I mean... don't you see a problem relying on _their own publication_ to
say what they are doing, when they
might like to keep their methods quiet to avoid negative attention?
Changing NXDOMAIN queries to an ISP's _own_ recursive servers is old hat,
and not the issue.
What the FAQ doesn't tell you is that the Paxfire appliances can tamper
with DNS
traffic received from authoritative DNS servers not operated by the ISP.
A paxfire box can alter NXDOMAIN queries, and queries that respond with
known search engines' IPs.
to send your HTTP traffic to their HTTP proxies instead.
Ty, http://netalyzr.icsi.berkeley.edu/blog/
"
In addition, some ISPs employ an optional, unadvertised Paxfire feature that
redirects the entire stream of affected customers' web search requests to
Bing, Google, and Yahoo via HTTP proxies operated by Paxfire. These proxies
seemingly relay most searches and their corresponding results passively, in
a process that remains invisible to the user. Certain keyword searches,
however, trigger active interference by the HTTP proxies.
"
http://www.icir.org/christian/publications/2011-satin-netalyzr.pdf
http://newswire.xbiz.com/view.php?id=137208
Disappointing that certain nanog readers depend on information put out by the vendor to be 100% honest and forthcoming in what their product does.
There's more to hijacking queries/dns/etc then just ISPs mucking with queries. MitM attacks, SSL hijacking, etc is all a valid concern, and completely within the realm of the discussion here and this topic.
As pointed out, there are ISPs and whole countries who have no qualms with doing this type of thing. Further, who cares if the company says their product isn't made or won't do what it may be doing? We all know full well that people use products in ways they aren't meant or intended to be used.
When companies realize that they can't just transparently muck with traffic anymore because 90% of customer traffic is encrypted, do you really think, in all honesty, that companies won't find a way to regain this revenue stream, even if it runs afoul of laws/ethics/etc?
Not trying to be obtuse, but none of the technical docs you cite appear to talk about HTTP proxies nor does the newswire report have any technical details. I have tested several of the networks listed in the report and in none of the cases I saw was there HTTP proxy activity. Picking up on WCCP/TCS isn't that hard (I used to install those myself) so unless there is some functionality in IOS and/or JUNOS that allows I don't see it happening. Paxfire can operate all of the proxies they want but the network infrastructure has to be able to pass the traffic over to those proxies and I don't see it (on at least 3 of the networks cited).
I can confirm the report is about DNS providers that are doing hijacking by
sending the traffic through dedicated proxies, either in the ISP's network
or in the DNS provider's network.
If you didn't see this happening, it might be because you were testing on
www.google.com rather than on Yahoo or Bing traffic. While the hijacking
*used* to affect Google also, we took a fairly aggressive stance and got it
stopped a while ago. The fact that there are no currently-known cases where
it affects Google was unfortunately not made clear in the Netalyzer/EFF
reports. If any of you find evidence of hijacking of Google, please shoot
me an email with details (DNS server, destination IP, etc) and I'll do what
I can to get it stopped.
Damian