Most Alarming: IETF Draft Proposes "Trusted Proxy" In HTTP/2.0 177
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."
Re:if you want a trusted proxy.. (Score:5, Interesting)
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.
Re:if you want a trusted proxy.. (Score:5, Interesting)
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.
I don't see what the fuss is about. (Score:5, Interesting)
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.
Misleading summary (Score:2, Interesting)
From the *actual* draft:
This document describes two alternative methods for an user-agent to
automatically discover and for an user to provide consent for a
Trusted Proxy to be securely involved when he or she is requesting an
HTTP URI resource over HTTP2 with TLS. The consent is supposed to be
per network access. The draft also describes the role of the Trusted
Proxy in helping the user to fetch HTTP URIs resource when the user
has provided consent to the Trusted Proxy to be involved.
The entire draft is oriented around user consent and transparency to the user... where is the problem here?
The linked article by Lauren Weinstein is very heavy on sarcasm, scorn and flippant one-liners, but pretty light on technical details. From what I can discern, her primary concern is that ISP's will force all of their users to consent to them acting as a trusted proxy or refuse to serve them.
This is pretty far fetched, imho. First of all, the backlash from the average consumer would be staggering. If, every time they go to their bank's web page, they get a scary security notice "do you want to allow an intermediary at "trustedproxy.verizon.com" to see your private data?" they answer, every time, will be "hell no". And if they are then unable to access their bank account because of this... well, that's not going to be a pretty picture for L1 support.
Second, the *last* thing most ISPs want is to have to deal with yet more PCI concerns. If they end up storing your cc number and ssn in a plain-text cache, that introduces all sorts of potential problems for them.
It seems like the primary use case for this technology is in serving media-heavy content that SSL screws up, like streaming video over ssl etc... so, it would allow caching etc for various media streams that really don't need SSL. And the user could make the decision for whether they want to do it or not.
This seems like a pretty smart thing to me, I'm not sure what all the hand-wringing is about. Maybe I'm missing something obvious?