Re: MITM and proxy messages [was: Call for Adoption: draft-song-dns-wireformat-http]

----- Mail original -----
De: "Mark Nottingham" 
Objet: MITM and proxy messages [was: Call for Adoption: draft-song-dns-wireformat-http]

> Would this help?

> https://mnot.github.io/I-D/proxy-explanation/

> Keep in mind that only helps for configured proxies. 

For private proxies it would help. Corps would probably be ok with dumping proxy page chrome as long as it is encrypted to avoid spoofing, the user agent warns if the cert changes, and browsers do not do the usual "end of the world" generic message

It's still missing a huge part however: proxy auth. There is no wish to allow a random attacker to drill through corp firewalls just by plugging a gadget on a free ethernet port

I don't see it work for public commercial captive portals (without necessary a proxy behind) such a the one I'm currently using. Those guys want to display their brand proheminently if only to tell people "look, if you was my customer, you could use the free-for-my-customers hotspot I deployed deep in this remote place" (which means auth again to prove you are a customer or paid a on-off fee, + reauth because reception of such hotspots is flacky and the connexion needs restablishing every time you move out of range).

As for the "but banks" objections it would be time for browsers people to realise banks do *not* design their sites any different than otherq, and all the efforts those past years to allow http mashups, third party adds, tracking cookies mean there is no way to check bank web sites anymore. They now call third-party js, add agency, just like the others. They may lag a little (on-two years) but the result is the same.

It is not possible to promote hoplessly insecure practices for some sites and hope they won't spread.

Received on Sunday, 7 August 2016 08:10:01 UTC