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
That works for you, me, and maybe a few other people.
For the billions of people online who don't/can't/won't think about what's actually going on, it doesn't work at all. In effect, all that matters is what Joe Sixpack does, and that's pretty clear. You can manipulate Joe into anything you want, by putting a shiny icon on it and telling him he can watch NFL Cheerleader Tryouts 15 in glorious High Definition.
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.
You have no clue what you are talking about. The "legally required" shit is already being done. There's no need to do any IETF crap.
This is for ISPs to do it to you, without you being able to prevent it.
But as I read it, the issue seems to arise from the fact that HTTP2 will permit TLS to be used with both http: and https: URLs. If it is used for http: URLs, then existing proxy and caching mechanisms will simply break. I think this is a proposal for "trused proxies" to be permitted where an http: URL is in use and TLS is also employed, I don't think it's proposed that this should apply to https: URLs.
In other words, it doesn't make things any worse than the current situation (where http: URLS are retrieved in plain text all the time) and does permit the user to control whether they want some protection against interception or potentially better performance. And it doesn't appear to change the situation for https: at all.
Or that's how it appears to me.
If you want to do this now, you're typically in one of two situations:
You need to proxy the traffic for all users of a company, in order to filter NSFW content and to scan for viruses and other malware. In this case you add your own CA to all company computers. Then you MITM all SSL connections. This doesn't work for certain applications which use built-in lists of acceptable CAs, but mostly the users will be none the wiser.
The other situation is that you want a reverse proxy in front of your hosting infrastructure. In this case you just have the proxy operator install your certificate and make it look like the proxy is your actual server.
In both cases, the Trusted Proxy extension would make more transparent what's actually going on, instead of pretending that there is no proxy when in fact there is.
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.
What is going to happen to all those secure credit card transactions that are the life-blood of internet commerce, when third parties figure out how to decrypt packets en-route by infiltrating the procedures of ISP's and alter them to "achieve efficiencies"?
You would think capitalists have a lot to loose if this proposal goes forward.
Is that Section 7, "Privacy Considerations," has no content.
It's only trusted by you if you assert that it is. This proposal formalizes the act of notifying of an available proxy and allowing the user to trust (or not trust) said proxy.
Mod me down, my New Earth Global Warmingist friends!
While the article justifiably blows a whistle on what could be an abuse or power, the premise of the article is BS at best. It suggests that the tech could be used to maliciously snoop on people without their knowledge. The spec says nothing of the sort. It allows a user to make use of a proxy. In the case of a TLS only HTTP 2.0, this is needed. Without it, people like myself would have to setup VPNs for management of infrastructure. I can instead make a web based authenticated proxy server which would permit me to manage servers and networks in a secure VPN environment where end to end access is not possible.
Additional benefits of the tech will be to create outgoing load balanced for traffic which add additional security.
How about protecting users privacy by using this tech. If HTTPv2 is any good for security, deep packet inspection will not be possible and as a result all endpoint security would have to exist at the endpoint. Porn filters for kids? Anti-virus for corporations? Popup blockers?
How about letting the user make use of technology like antivirus on their own local machine to improve their experience? How many people on slashdot use popup blockers which work as proxies on the same machine.
This tech adds to their security end-to-end instead. After all, it allows a user to explicitly define a man-in-the-middle to explicitly trust applications and appliances in the middle to improve their experience.
What about technology like Opera mini which cuts phone bills drastically or improves performance by reducing page size in the middle.
Could the tech be used maliciously? To a limited extent... Yes. But it is far more secure than not having such a standard and still using these features. By standardizing a means to explicitly define trusted proxy servers, it mitigates the threat of having to use untrusted ones.
Where does it become a problem? It'll be an issue when you buy a phone/device from a vendor who has pre-installed a trusted proxy on your behalf. It can also be an issue if the company you work for pushes out a trusted proxy via group policy that now is able to decrypt more than what it should.
I haven't read the spec entirely, but I would hope that banks and enterprises will be able to flag traffic as "do not proxy" explicitly so that endpoints will know to not trust proxies with that information.
Oh... And as for tracking as the writer suggests... While we can't snoop the content, tools like WCCP, NetFlow, NBAR (all Cisco flavors) as well as transparent firewalls and more can already log all URLs and usage patterns without needing to decrypt.
So... May I be so kind as to simply say "This person is full of shit" and move on from there?
If you don't *TRUST* the proxy, don't accept it's use.
That's true. But then, if you're a user who's not very security savvy (like 95% of the people on the internet) and you think "https is secure, my isp can't see my data", and you think "secure proxy, sounds good!", then you're stuffed. Either the rfp should require isps to notify their customers that "secure" in this case means "secure, but we can see it", or the rfp should describe a solution where the isp really can't see the users data.
no, I don't have a sig
Sure, you have a "choice" whether or not to trust a particular proxy, but in many cases it's a Hobson's choice: "Trust us or we block all your packets." If all ISPs willing to offer service to you offer a choice between their proxy or no Internet access, are you willing to take no Internet access? Would enough other home users agree with you to make serving them profitable?
This is also from the *actual* draft:
7. Privacy Considerations
Notice how it's empty? The author(s) plainly don't give two hoots about use privacy.
"someone didn't RTFM!"
And apparently that someone was not alone.
Right there on the first page it also says it calls for a mechanism for the person making the request to provde consent for the "trusted" proxy to, well, be a proxy.
Granted, there could be problems with people consenting when they shouldn't. There might also be problems with essentially coerced "consent", as in a situation where that is the only avenue for accessing that resource. But those are different problems than that of someone just inserting themselves in as a man-in-the-middle.
You have no clue what you are talking about. The "legally required" shit is already being done. There's no need to do any IETF crap.
This is for ISPs to do it to you, without you being able to prevent it.
Really? Because the draft says that the end user must explicitly given permission for every session(no "always agree" option). You really think FireFox and Chrome will not prompt the user and ask them if they want to use the proxy? If they didn't, I guarantee that someone would immediately fork the projects and make them work that way.
TLS would indicate a man in the middle by means of a certificate warning. Now imagine getting a warning that the certificate is signed by your ISP for every single HTTPS site you visit other than your ISP's own site. You check the knowledgebase on the ISP's site and find a statement to the effect: "Either you accept our proxy certificate or you don't get to connect."
In the vast majority of cases, when you are using an encrypted connection it is because the information you are exchanging is a private matter between you and the other endpoint.
Even if the only private piece of information is the session cookie identifying the logged-in user to the site, that's still "a private matter between" the user and the site. Since the Firesheep tech demo became public, it has become common for some web sites to go all HTTPS all the time to prevent intruders from snooping and replaying session cookies. Facebook and Twitter do this, and Wikipedia turned it at the end of August of last year. The biggest historical obstacle to HTTPS implementation for any site on a VPS or bigger has been mixed content introduced by ad networks, but in September of last year, Google finally enabled HTTPS for AdSense.
So does installing the Ask Toolbar, but I'll be damned if I can find anyone who knew they had consented to installing it...