[Cryptography] phishing, was Encryption opinion

[Jerry Leichter]

On Sep 8, 2014, at 11:45 PM, John Levine <johnl at iecc.com> wrote:
>>   "Comcast Wi-Fi serving self-promotional ads via JavaScript injection"
>> 
>> If carriers and others are permitted to inject anything the framework
>> for MITM attacks is established and made legal.
> This battle was lost long, long ago.  ISPs routinely intercept
> NXDOMAIN DNS results and replace them with A records pointing to a web
> server with "helpful" paid ads.
I've always found this one complicated.  If done without the end user's permission, it's an issue.  But there are people who believe it's bad even *with* the end-user's permission - for reasons I find hard to follow.

> On mobile networks, it's very common
> to force web traffic through caches, and to re-encode images to
> smaller versions appropriate for the tiny screens.
Of course, the Web site providers all do this themselves - with mobile versions of their sites and various edge distribution networks.  So this all descends into layers of fuzz, and in this case in particular you get into the whole question of "who benefits"?  "Who pays extra costs" (whether in dollars, damaged data - the site isn't as usable as it should be, "stolen attention" paid to ads, whatever).  For a simple point to point connection between Alice and Bob, who the "man in the middle" is is clear. When a single page on the Web has contributions from tens to hundreds of servers for ads, tracking, and who knows what - not to mention multiple network and edge service providers - it becomes very vague.

> ...There's a couple of companies with names I forget (no doubt they want
> me to) who produce specialist equipment to do DPI and replace packets
> like this.
http://arstechnica.com/tech-policy/2014/09/meet-the-tech-company-performing-ad-injections-for-big-cable/

> Most of the web nonsense can be prevented with https, at least if you
> have an honest browser that doesn't interpret https as "tell the cache
> at the ISP to fetch the https version".
Indeed.
                                                        -- Jerry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4813 bytes
Desc: not available
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20140909/99b34ff8/attachment.bin>