Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

ISP Advertisement Injection - CMA Communications

zmhenkel.blogspot.com

Post reply on HN
Print view View original

51–60 of 81 posts

Re: ISP Advertisement Injection - CMA Communications

#51

Post by jiggy2011 »

alepper wrote: post #43
jiggy2011 wrote: post #25

Earlier quoted context omitted.

Wouldn't this depend on the TOS of the ISP? Perhaps by signing the contract you "authorise" this. This sort of thing doesn't surprise me any more. AFAIK DNS on every major ISP in the UK is broken, there is no NXDOMAIN. Unresolvable domains are simply redirected to a specific IP address which happens to host a page of ads and a search bar on port 80. This might not matter to most people, but it's a huge PITA when I'm…

FWIW, I haven't noticed this on any of BT, Sky or Virgin.

NXDOMAIN is hijacked on Virgin Media for sure, unless you are using some other DNS. I haven't noticed them injecting ads though.

Re: ISP Advertisement Injection - CMA Communications

#52

Post by tomsthumb »

jiggy2011 wrote: post #29
ConstantineXVI wrote: post #27

Earlier quoted context omitted.

I'm not aware of any similar arguments being tested in court, so this is all conjecture. That said, barring an explicit definition of 'Internet service' in your service contract, it's commonly understood that requesting a page from example.com, all the data your ISP returns implicitly is sourced from example.com. Introducing your own content in between is therefore fraud, as you've mis-represented the origin of the c…

But in such a case you could make the same argument for ad supported wifi connections or proxies.

You do enter into agreement (usually), but do you have a valid contract when using those connections?

Re: ISP Advertisement Injection - CMA Communications

#53

Post by joshAg »

dchest wrote: post #31
joshAg wrote: post #28

Earlier quoted context omitted.

https is the wrong solution. that is for preventing others from seeing what you're sending/receiving, not verifying the integrity of what is sent/received. well, it does do that too, but it adds extra unneeded overhead by encrypting everything. Besides, the ISP can easily man-in-the-middle any connection you make and then inject their ads into the webpage, even if you use https. The correct solution is signing the we…

Ha-ha, and let's call this HTTPSEC http://cr.yp.to/talks/2013.02.07/slides.pdf ! (Spoiler: HTTPSEC is not a real thing, it's what we'd had if people who invented DNSSEC, or people like the parent commenter, designed something like TLS).

wow, that is an annoying slide deck. a lot of the issues seemed to be dns-specific that don't exist with http (slide 110: "Attacker forges many UDP request packets from victim’s IP address to many HTTPSEC servers.", also exist for https (slide 106: "Each HTTPSEC key/signature is another file to retrieve. Often your browser needs a chain of keys from several servers. Could be a serious slowdown."), or were self contradictory (slide 13 says httpsec "allow[s] for verification of the origin, authenticity, and integrity of data' obtained through http", but slide 123 says "The data signed by HTTPSEC doesn’t actually include the web pages that the browser shows to the user". I think the HTTPSEC you are referencing is partly a straw man, because that httpsec does the opposite of what I proposed, which was signing the webpage itself, not the redirect info. I do have some questions about issues brought up in the slides:

is the delay/cost of signing versus encrypting data really so huge that it's infeasible to sign dynamic pages?

also, why does each non-existent http page need it's own 404? Wouldn't a static 404 response be just fine?

Re: ISP Advertisement Injection - CMA Communications

#54

Post by ams6110 »

jcr wrote: post #8
richardwhiuk wrote: post #4

HTTPS everywhere would solve this, and the Comcast Javascript injection - I wonder how many more people will deploy things like this before that happens?

Actually, the "HTTPS Everywhere" plugin [1] for firefox and chrome is an incomplete solution. The reason is simple; not all sites support HTTPS, so the plain HTTP-only sites are still vulnerable. Injecting a script into insecure HTTP is just one of many abuses possible by ISP's. Replacing images on the fly is another. Recompressing (degrading) images/video is another. Messing with DNS responses is another, and so on.…

tunnelr.com... "Powered by OpenBSD"... I like it already.

Re: ISP Advertisement Injection - CMA Communications

#55

Post by daxelrod »

joshAg wrote: post #28
richardwhiuk wrote: post #4

HTTPS everywhere would solve this, and the Comcast Javascript injection - I wonder how many more people will deploy things like this before that happens?

https is the wrong solution. that is for preventing others from seeing what you're sending/receiving, not verifying the integrity of what is sent/received. well, it does do that too, but it adds extra unneeded overhead by encrypting everything. Besides, the ISP can easily man-in-the-middle any connection you make and then inject their ads into the webpage, even if you use https. The correct solution is signing the we…

> Besides, the ISP can easily man-in-the-middle any connection you make and then inject their ads into the webpage, even if you use https.

How would they do this without triggering certificate warnings? Or are you simply saying that everyone ignores certificate warnings?

Re: ISP Advertisement Injection - CMA Communications

#56

Post by marshray »

HarryHirsch wrote: post #9
revelation wrote: post #6

Earlier quoted context omitted.

You shouldn't have to encrypt your data to stop your ISP from actively 1) scanning and 2) corrupting it. What is the FCC good for?

Indeed. What's with the Internet being a set of tubes?

And tubes based on the honor system at that.

Re: ISP Advertisement Injection - CMA Communications

#57

Post by marshray »

grecy wrote: post #14
johnvschmitt wrote: post #12

This was inevitable. That's why I bought Google stock after they got into Android, as Android makes it possible for Google to now step in & protect against the MITTM attacks by ISP's blocking their ads. The OS gets the final word before it displays content to the user & it can detect & block these. Now, they just have to deploy the fix to Android...

And what happens when Google are the one doing the MITTM attack? It all comes down to who do you trust.

Has Google ever modified other websites' pages like this?

Re: ISP Advertisement Injection - CMA Communications

#58

Post by marshray »

joshAg wrote: post #28
richardwhiuk wrote: post #4

HTTPS everywhere would solve this, and the Comcast Javascript injection - I wonder how many more people will deploy things like this before that happens?

https is the wrong solution. that is for preventing others from seeing what you're sending/receiving, not verifying the integrity of what is sent/received. well, it does do that too, but it adds extra unneeded overhead by encrypting everything. Besides, the ISP can easily man-in-the-middle any connection you make and then inject their ads into the webpage, even if you use https. The correct solution is signing the we…

> adds extra unneeded overhead by encrypting everything

Baloney. :-) Or rather, please cite something in the last 5 years showing that the overhead of the symmetric encryption is a significant cost in HTTPS.

Re: ISP Advertisement Injection - CMA Communications

#59

Post by marshray »

joshAg wrote: post #53
dchest wrote: post #31

Earlier quoted context omitted.

Ha-ha, and let's call this HTTPSEC http://cr.yp.to/talks/2013.02.07/slides.pdf ! (Spoiler: HTTPSEC is not a real thing, it's what we'd had if people who invented DNSSEC, or people like the parent commenter, designed something like TLS).

wow, that is an annoying slide deck. a lot of the issues seemed to be dns-specific that don't exist with http (slide 110: "Attacker forges many UDP request packets from victim’s IP address to many HTTPSEC servers.", also exist for https (slide 106: "Each HTTPSEC key/signature is another file to retrieve. Often your browser needs a chain of keys from several servers. Could be a serious slowdown."), or were self contra…

It was meant to be a jab at DNSSEC, so yeah it's probably nonsensical if you try to read it as a real HTTP proposal.

Re: ISP Advertisement Injection - CMA Communications

#60

Post by marshray »

derleth wrote: post #46
koenigdavidmj wrote: post #16

Earlier quoted context omitted.

That's a good way to get yourself the CA death penalty.

So? If Comcast does it, what are they going to do?

A few financial institutions holding large quantities of Comcast's paper (and their executives' IRAs) pick up the phone and explain how they feel about having their secure websites' identity impersonated.
Post reply on HN