US internet providers hijacking users' search queries
On Fri, Aug 05, 2011 at 05:04:51PM -0700, Bino Gopal wrote:
http://www.newscientist.com/article/dn20768-us-internet-providers-hijacking-...
I hope more ISPs start doing this; it'll increase the take up of HTTPS. - Matt -- Part[s] of .us are the global benchmark for pumpkin being a verb. -- Anthony de Boer
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? -- Brielle (sent from my iPhone) On Aug 5, 2011, at 6:45 PM, Matthew Palmer <mpalmer@hezmatt.org> wrote:
On Fri, Aug 05, 2011 at 05:04:51PM -0700, Bino Gopal wrote:
http://www.newscientist.com/article/dn20768-us-internet-providers-hijacking-...
I hope more ISPs start doing this; it'll increase the take up of HTTPS.
- Matt
-- Part[s] of .us are the global benchmark for pumpkin being a verb. -- Anthony de Boer
On 08/05/2011 02:53 PM, Brielle wrote:
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?
In message <4E3C9228.4050808@paulgraydon.co.uk>, Paul Graydon writes:
On 08/05/2011 02:53 PM, Brielle wrote:
Until they start MitM the ssl traffic, fake certs and all. Didn't a certai n repressive regime already do this tactic with facebook or some other major site?
Syria did: https://www.eff.org/deeplinks/2011/05/syrian-man-middle-against-facebook<http s://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 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On Aug 5, 2011, at 6:03 PM, Mark Andrews wrote:
In message <4E3C9228.4050808@paulgraydon.co.uk>, Paul Graydon writes:
On 08/05/2011 02:53 PM, Brielle wrote:
Until they start MitM the ssl traffic, fake certs and all. Didn't a certai n repressive regime already do this tactic with facebook or some other major site?
Syria did: https://www.eff.org/deeplinks/2011/05/syrian-man-middle-against-facebook<http s://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.
Unless they start proxying all queries and putting their own trust anchors on all the results. Owen
In message <D8FBCDCB-BCD1-4847-9D23-D5745A5C609B@delong.com>, Owen DeLong write s:
On Aug 5, 2011, at 6:03 PM, Mark Andrews wrote:
=20 In message <4E3C9228.4050808@paulgraydon.co.uk>, Paul Graydon writes:
On 08/05/2011 02:53 PM, Brielle wrote:
Until they start MitM the ssl traffic, fake certs and all. Didn't a = certai n repressive regime already do this tactic with facebook or some = other major=20 site? =20 Syria did:=20 = https://www.eff.org/deeplinks/2011/05/syrian-man-middle-against-facebook<h= ttp s://www.facebook.com/note.php?note_id=3D10150178983622358&comments>=20=
=20 Which is countered by DNSSEC + DANE. A country may be able to fake = everything under their tld but not the rest of the net. =20 Unless they start proxying all queries and putting their own trust = anchors on all the results.
Which still won't work unless they can get a false trust anchor for the root installed. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On 8/5/2011 8:53 PM, Brielle wrote:
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?
Marketscore did (via installing root certs in the victim's machines), and as far as I know, still does. Jeff
On Fri, Aug 05, 2011 at 06:53:50PM -0600, Brielle wrote:
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?
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 -- There's a term for those who fantasize that the world works in precisely the way that produces maximum convenience for them, despite years of evidence to the contrary. The term is "Morons". -- Greg Andrews, in the Monastery
On Fri, Aug 5, 2011 at 7:45 PM, Matthew Palmer <mpalmer@hezmatt.org> wrote:
On Fri, Aug 05, 2011 at 05:04:51PM -0700, Bino Gopal wrote:
http://www.newscientist.com/article/dn20768-us-internet-providers-hijacking-... I hope more ISPs start doing this; it'll increase the take up of HTTPS. - Matt
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.... -- -JH
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 On Fri, Aug 5, 2011 at 6:10 PM, Jimmy Hess <mysidia@gmail.com> wrote:
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.
On Fri, 05 Aug 2011 17:04:51 PDT, Bino Gopal said:
http://www.newscientist.com/article/dn20768-us-internet-providers-hijacking-...
Thoughts?
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.
On Fri, Aug 05, 2011 at 05:04:51PM -0700, Bino Gopal wrote:
http://www.newscientist.com/article/dn20768-us-internet-providers-hijacking-...
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. -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE / NewNOG
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). On 8/5/2011 9:14 PM, Joe Provo wrote:
On Fri, Aug 05, 2011 at 05:04:51PM -0700, Bino Gopal wrote:
http://www.newscientist.com/article/dn20768-us-internet-providers-hijacking-... 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.
-- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms --------------------------------
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 On Aug 6, 2011, at 7:41 AM, Scott Helms wrote:
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).
On 8/5/2011 9:14 PM, Joe Provo wrote:
On Fri, Aug 05, 2011 at 05:04:51PM -0700, Bino Gopal wrote:
http://www.newscientist.com/article/dn20768-us-internet-providers-hijacking-... 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.
-- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms --------------------------------
On Sat, Aug 06, 2011 at 10:41:10AM -0400, Scott Helms wrote:
Correct, I don't believe that any of the providers noted are actually [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. -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE / NewNOG
On Sat, Aug 6, 2011 at 12:08 PM, Joe Provo <nanog-post@rsuc.gweep.net>wrote:
On Sat, Aug 06, 2011 at 10:41:10AM -0400, Scott Helms wrote:
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 -- -JH
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).
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
-- -JH
-- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms --------------------------------
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 On Sat, Aug 6, 2011 at 7:03 PM, Scott Helms <khelms@ispalliance.net> wrote:
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).
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/<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://www.icir.org/christian/publications/2011-satin-netalyzr.pdf> http://newswire.xbiz.com/view.**php?id=137208<http://newswire.xbiz.com/view.php?id=137208>
-- -JH
-- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 ------------------------------**-- http://twitter.com/kscotthelms ------------------------------**--
-- Damian Menscher :: Security Reliability Engineer :: Google
On Sat, Aug 6, 2011 at 10:03 PM, Scott Helms <khelms@ispalliance.net> wrote:
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'. (198.6.1.1 has a paxfire appliance literally in-line between it's customer facing port and the world) 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 64.158.56.49 asdkjad912jd.123adsad.com. 60 IN A 63.251.179.49 ;; 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. -chris
On Aug 8, 2011 4:24 PM, "Christopher Morrow" <morrowc.lists@gmail.com> wrote:
On Sat, Aug 6, 2011 at 10:03 PM, Scott Helms <khelms@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
wrote: 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'. (198.6.1.1 has a paxfire appliance literally in-line between it's customer facing port and the world)
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 64.158.56.49 asdkjad912jd.123adsad.com. 60 IN A 63.251.179.49 ;; 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.
-chris
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 feature....imho Cb
On Mon, Aug 8, 2011 at 7:47 PM, Cameron Byrne <cb.list6@gmail.com> wrote:
On Aug 8, 2011 4:24 PM, "Christopher Morrow" <morrowc.lists@gmail.com> wrote:
On Sat, Aug 6, 2011 at 10:03 PM, Scott Helms <khelms@ispalliance.net> wrote:
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'. (198.6.1.1 has a paxfire appliance literally in-line between it's customer facing port and the world)
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 64.158.56.49 asdkjad912jd.123adsad.com. 60 IN A 63.251.179.49 ;; 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.
-chris
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 feature....imho
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. -chris
Chris, On Aug 8, 2011, at 2:56 PM, Christopher Morrow wrote:
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.
See that ship off on the horizon? It appears to have sailed... I'm told that non-trivial revenue is being generated by ISPs who are doing this redirection. As long as that is true, I suspect it's unlikely pointing out how broken hijacking DNS is will be particularly effective. Regards, -drc
On Mon, Aug 8, 2011 at 11:52 PM, David Conrad <drc@virtualized.org> wrote:
Chris,
On Aug 8, 2011, at 2:56 PM, Christopher Morrow wrote:
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.
See that ship off on the horizon? It appears to have sailed...
doesn't mean I can't be the cranky old man shaking my fist, right?
I'm told that non-trivial revenue is being generated by ISPs who are doing this redirection. As long as that is true, I suspect it's unlikely pointing out how broken hijacking DNS is will be particularly effective.
yea... so that, so I understand, depends a lot on who's telling the tale. From one source at an ISP doing this, the revenues are not anywhere near what was promised by the vendor(s). Anyway, I'm not sure what they are, we probably won't ever know what they really are :( I suppose it'll continue as long as people consider it 'ok' to be subjected to this and don't leave their ISP for an alternative. (where available!) Oh, maybe dns-sec will help us with this problem too? nsec3 to the rescue?
On Sat, Aug 06, 2011 at 01:25:18PM -0500, Jimmy Hess wrote:
On Sat, Aug 6, 2011 at 12:08 PM, Joe Provo <nanog-post@rsuc.gweep.net>wrote:
On Sat, Aug 06, 2011 at 10:41:10AM -0400, Scott Helms wrote:
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'm not jumping to conclusions, merely speaking to evidence. My personal experience involves leaving a job at a network that insisted on implementing some of this dreck. There is a well-known, long-standing "monetization" by breaking NXDOMAIN. DSLreports and plenty of other end-user fora have been full of information regarding this since Earthlink starded doing it in ... 2006?
Changing NXDOMAIN queries to an ISP's _own_ recursive servers is old hat, and not the issue.
That sentence makes no sense. Hijacking NXDOMAIN doesn't have anything to do with pointing to a recursive resolver, but returning a partner/ affiliate web site, search "helper" site or proxy instead of the NXDOMAIN.
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.
This is finally something new, and I retract my assertion that the new scientist got it wrong. Drilling through to actual evidence and details, rather than descriptions which match previous behavior, we have both http://www.usenix.org/event/leet11/tech/full_papers/Zhang.pdf (a little indirect with 'example.com', etc) and http://www.payne.org/index.php/Frontier_Search_Hijacking (with actual domains) provide detail on the matter. Cheers! Joe -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE / NewNOG
On 8/7/11 12:10 PM, Joe Provo wrote:
This is finally something new, and I retract my assertion that the new scientist got it wrong. Drilling through to actual evidence and details, rather than descriptions which match previous behavior, we have both http://www.usenix.org/event/leet11/tech/full_papers/Zhang.pdf (a little indirect with 'example.com', etc) and http://www.payne.org/index.php/Frontier_Search_Hijacking (with actual domains) provide detail on the matter. Cheers! Joe I noticed that the payne.org link calls out the insertion of an Amazon affiliate code. Section 7 of the Amazon affiliate agreement (https://affiliate-program.amazon.com/gp/associates/agreement) appears to explicitly prohibit payment for this type of traffic.
Oren
On Mon, Aug 8, 2011 at 7:57 PM, Oren Levin <lists@pinetree.net> wrote:
On 8/7/11 12:10 PM, Joe Provo wrote:
This is finally something new, and I retract my assertion that the new scientist got it wrong. Drilling through to actual evidence and details, rather than descriptions which match previous behavior, we have both http://www.usenix.org/event/leet11/tech/full_papers/Zhang.pdf (a little indirect with 'example.com', etc) and http://www.payne.org/index.php/Frontier_Search_Hijacking (with actual domains) provide detail on the matter. Cheers! Joe
I noticed that the payne.org link calls out the insertion of an Amazon affiliate code. Section 7 of the Amazon affiliate agreement (https://affiliate-program.amazon.com/gp/associates/agreement) appears to explicitly prohibit payment for this type of traffic.
interesting, one wonders if maybe amazon will 'do the right thing' (much like they did with wikileaks?) and remove the account's access.
On 8/6/11 11:08 AM, Joe Provo wrote:
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 readhttp://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.
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? -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org
participants (18)
-
Bino Gopal -
Bradford Chatterjee -
Brielle -
Brielle Bruns
-
Cameron Byrne -
Christopher Morrow -
Damian Menscher -
David Conrad -
Jeff Kell -
Jimmy Hess -
Joe Provo -
Mark Andrews -
Matthew Palmer -
Oren Levin -
Owen DeLong -
Paul Graydon -
Scott Helms -
Valdis.Kletnieks＠vt.edu