Sprint is another (lesser?) offender -- their mobile broadband injects a script in every page that loads compressed versions of images until told otherwise. (Annoying, but at least it's well-intentioned.) I've long since blocked the IP, but it gave me a bit of a scare to see unfamiliar code in my own websites.
ISP Advertisement Injection - CMA Communications
71–80 of 81 posts
Re: ISP Advertisement Injection - CMA Communications
#72Damn, that is low. Time to get a vpn.
Re: ISP Advertisement Injection - CMA Communications
#73Re: ISP Advertisement Injection - CMA Communications
#74Earlier quoted context omitted.
assuming you just want to browse websites and not transfer information that needs to be private, the extra rtt for establishing the ssl connection is the uneeeded overhead. for something like streaming a movie, that won't matter because the ssl connection will be long lived. for something like web browsing, where most websites require a new tcp connection for each GET, ssl is painful. sure, the extra rtt is preferabl…
Note that the primary HTML resource for most web pages takes multiple roundtrips to transmit completely. If you sign it only at the end, you've made the browser feel slower. So you'd have to avoid the RTT by accepting, processing, and presenting the data immediately but only later authenticating it retroactively. The bad guy can just drop or delay the legitimate signature. This is inherently error-prone. It gives the…
The issues with bad guys dropping the sig or delaying it also equally applies equally to ssl during the handshake. But waiting for the sig and the whole page to arrive combined wit the size of modern webpages is a problem I hadn't fully considered. I suppose per packet signatures might work to fix the delay issue, but then you'd have to violate abstraction layers and the added cpu time would be completely untenable. At that point you might as well just copy ssl's dh handshake followed by a block cypher but only provide integrity and not privacy, which is stupid. yeah, ok I'm convinced, stupid idea due to practical reasons. just use https with the extra rtt's.
Re: ISP Advertisement Injection - CMA Communications
#75Earlier quoted context omitted.
Note that the primary HTML resource for most web pages takes multiple roundtrips to transmit completely. If you sign it only at the end, you've made the browser feel slower. So you'd have to avoid the RTT by accepting, processing, and presenting the data immediately but only later authenticating it retroactively. The bad guy can just drop or delay the legitimate signature. This is inherently error-prone. It gives the…
The issues with bad guys dropping the sig or delaying it also equally applies equally to ssl during the handshake. But waiting for the sig and the whole page to arrive combined wit the size of modern webpages is a problem I hadn't fully considered. I suppose per packet signatures might work to fix the delay issue, but then you'd have to violate abstraction layers and the added cpu time would be completely untenable.…
It's not a stupid idea, it's a problem that smart folks have been banging their head against for a long time now. Take a look at the "TLS Snap Start" proposal to see the lengths to which one must be willing to go to avoid that round trip.
But some low-hanging fruit remains. Improvements to clients and servers that increase TLS session resumption rates would help too.
Re: ISP Advertisement Injection - CMA Communications
#76HTTPS 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.…
I meant actually demanding that content providers deploy HTTPS everywhere instead.
Re: ISP Advertisement Injection - CMA Communications
#77HTTPS 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…
If the ISP can MITM the HTTPS connection (hint: they can't because they can't provide a valid certificate which matches the domain which has been signed by a trusted CA), they can MITM any signing system you may come up with.
Google has already provided statistics showing that HTTPS adds a negligible amount of CPU load to servers (and most websites aren't CPU bound anyway).
Re: ISP Advertisement Injection - CMA Communications
#78Earlier quoted context omitted.
Has Google ever modified other websites' pages like this?
Yes, I believe they call it Adsense.
https://en.wikipedia.org/wiki/AdSense "How AdSense works
(1) The webmaster inserts the AdSense JavaScript code into a webpage."
So this is the webmaster modifying his own page. It's not Google injecting Javascript into someone else's page like CMA Communications or Comcast is said to be doing.
Re: ISP Advertisement Injection - CMA Communications
#79Earlier quoted context omitted.
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.…
I meant actually demanding that content providers deploy HTTPS everywhere instead.
Sorry about that. It seems my reading comprehension skills are still flawed. ;)
Re: ISP Advertisement Injection - CMA Communications
#80HTTPS 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.…
And here's your annual reminder of the upside-down-ternet
http://www.ex-parrot.com/pete/upside-down-ternet.html