Slashdot Mirror
Most Alarming: IETF Draft Proposes "Trusted Proxy" In HTTP/2.0
Lauren Weinstein writes "You'd think that with so many concerns these days about whether the likes of AT&T, Verizon, and other telecom companies can be trusted not to turn our data over to third parties whom we haven't authorized, that a plan to formalize a mechanism for ISP and other 'man-in-the-middle' snooping would be laughed off the Net. But apparently the authors of IETF (Internet Engineering Task Force) Internet-Draft 'Explicit Trusted Proxy in HTTP/2.0' (14 Feb 2014) haven't gotten the message. What they propose for the new HTTP/2.0 protocol is nothing short of officially sanctioned snooping."
someone didn't RTFM!
and do what with the data then?
The main point of a proxy here is to allow things like caching, so you connect to the proxy using an encrypted pipe and as the proxy is trusted, you allow it to de-crypt your data, do whatever network efficiencies it wants to do and then re-encrypt your data to pass on to the destination.
I'm sure you can see why this might be a problem - your encrypted, secure data is automatically decrypted right at the point the NSA (or your ISP) wants it. Now if you trust your ISP or NSA to protect you and you don;t care if they are data mining your communications, then this is a great thing, let then do it as efficiently as possible.
if on the other hand, you think that the data you encrypt is done to stop others from performing man-in-the-middle attacks, then you'd not want this to be used.
Personally, I think its an ok thing as long as there's another mechanism for encrypting private data. I mean - you encrypt the boring stuff that you still don't want intercepted over a wifi link for example, but you still want your passwords to be properly encrypted and unreadable even by the trusted proxy. I would want the benefits of SSL on all my comms and have the benefits of proxy servers working with these, but still have my private data encrypted. I'm not sure how we could achieve this though, hopefully someone will enlighten me.
Also, she really needs a shave.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
Pretty much anyone can submit an IETF RFC if they really want. The existence of a draft does not guarantee a ratified version will exist someday.
For another, it could be much worse. There is explicit wording at least here about seeking consent from the user and allowing opt-out even in the 'captive' case, as well as notifying the actual webserver of this intermediary, and that the intermediary must use a particular keyusage field meaning that some trusted CA has explicitly approved it (of course, the CA model is pretty horribly ill-suited for internet scale security, but better than nothing). Remember how Nokia confessed they silently and without consent had their mobile browser hijack and proxy https traffic without explicitly telling the user or server? While something like this being formalized wouldn't prevent such a trick, it would be very hard to defend a secretive approach in the face of this sort of standard being in the wild.
Keep in mind that in a large number of cases in mobile, the carriers are handing people the device including the browser they'll be using. A carrier could do what Nokia admits to in many cases without the user being the wiser and claim the secretive aspect is just a side effect today. If there was a standard clearly laying out that a carrier or mobile manufacturer should behave a certain way, that defense would go away.
I would always elect the 'opt out' myself, but I'd prefer anything seeking to proxy secure traffic be steered toward doing things on the up and up rather than pretending no one will do it and leaving the door open for ambiguous intentions.
XML is like violence. If it doesn't solve the problem, use more.
You don't understand how things work, do you? This bypasses your "acceptance" requirement.
They can just do it transparently.
My employer uses a MITM HTTPS proxy. The IT department pushed down a trusted corporate certificate, and most people don't even know their HTTPS connections aren't secure any more. The real problem is when some application, other than a browser, needs internet access and it fails. This includ sethings like web installers that download the app during installation, automatic update systems, secure file transfer software, or things that call home to confirm a license key. On occassion a developer curses some installer for not working, then we inspect the install.log file and find something about a certificate failure.
IT departments forget that HTTPS is used for more than just browsing the web.
Lauren Weinstein is no lightweight; there's a good reason he's a Google consultant and have 400,000 followers. It's not for his singing & dancing.
Pain is merely failure leaving the body
It's already quite easy to add a * certificate to a browser to allow a proxy to intercept SSL. This is a standard practice in many LANs to allow the web filter to work on SSL pages - otherwise it'd be impossible to perform more than the most basic DNS/IP filtering on HTTPS sites, which would let a *lot* of undesired content through - google images alone would be quite the pornucopia.
All this proposal does is formalise the mechanism that people are already widely using. The end user still needs to explicitly authorise the proxy, no different than adding a * certificate today - and that's something so common, Windows lets you do it via group policy. The author's big fear seems to be that ISPs could start blocking everything unless the user authorises their proxy - and they could do that already, just be blocking everything unless the user authorises their * certificate!
And either way, they won't. For reasons of simple practicality. Sure, they could make the proxy authroisation process easy by giving a little 'config for dummies' executable. Easily done. Now repeat the same for the user's family with their three mobile phones (One android, one iOS, one blackberry), two games consoles, IP-connected streaming TV, the kid's PSP and DS (Or successor products), the tablet and the internet-connected burgler alarm. All of which will be using HTTP of some form to communicate with servers somewhere, and half of them over HTTPS, with the proportion shooting *way* up if HTTP/2.0 catches on.