US internet providers hijacking users' search queries
morrowc.lists at gmail.com
Mon Aug 8 19:56:32 CDT 2011
On Mon, Aug 8, 2011 at 7:47 PM, Cameron Byrne <cb.list6 at gmail.com> wrote:
> On Aug 8, 2011 4:24 PM, "Christopher Morrow" <morrowc.lists at gmail.com>
>> On Sat, Aug 6, 2011 at 10:03 PM, Scott Helms <khelms at ispalliance.net>
>> > 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).
>> barefruit/paxfire/nominum/etc all do essentially the same thing:
>> 1) install a dns-appliance in-line (some form of in-line, there are
>> lots of options, it's not really important in the end which is used)
>> between 'cache resolver' and 'user'. (22.214.171.124 has a paxfire
>> appliance literally in-line between it's customer facing port and the
>> 2) chose a set/subset of queries to falsify answers for (nxdomain
>> only? autosearch.msn.com? *.google.com? *?)
>> 3) run a farm of servers somewhere else (in the case of paxfire they
>> are the jomax.net servers:
>> ;; QUESTION SECTION:
>> ;asdkjad912jd.123adsad.com. IN A
>> ;; ANSWER SECTION:
>> asdkjad912jd.123adsad.com. 60 IN A 126.96.36.199
>> asdkjad912jd.123adsad.com. 60 IN A 188.8.131.52
>> ;; AUTHORITY SECTION:
>> asdkjad912jd.123adsad.com. 65535 IN NS WSC2.JOMAX.NET.
>> asdkjad912jd.123adsad.com. 65535 IN NS WSC1.JOMAX.NET.
>> In the case of barefruit it's another complex and in the case of
>> nominum it's a third complex ...
>> 4) accept http/https/etc on the complex of servers, funnel you an
>> answer which is essentially 'hostname == search-query'. For non-http
>> most of these complexes are SUPPOSED to not permit a connect to
>> happen... for jomax at least they don't accept tcp/443, they do accept
>> 25 though :(
>> 5) profit if users click on these results.
>> It's not black magic, it's annoying and wrong for some versions
>> (depending upon your ethics I guess?) of wrong :( I wish ISP's would
>> stop doing this, and it seems that some folk have luck twisting arms
>> at ISP's to make this stop.
> Some people believe the search results are a better user experience than the
> error page they would otherwise receive. The "awesome bar" is a similar
sure, but users requested that 'feature' and it's there for only
http/https traffic. it's not being done at the lower layers of the
stack, for all applications off the client machine.
messing with basic plumbing will have unintended consequences, they will be bad.
If the users her WANT to have this experience, there are lots of
in-browser/application methods to achieve this, hijacking DNS at the
resolver is really just NOT the right answer, ever.
More information about the NANOG