If you care about Internet security, especially what we call "end-to-end" security free from easy snooping by ISPs, carriers, or other intermediaries, heads up! You'll want to pay attention to this.

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.

Of course, they don't phrase it exactly that way.

You see, one of the "problems" with SSL/TLS connections (e.g. https:) -- from the standpoint of the dominant carriers anyway -- is that the connections are, well, fairly secure from snooping in transit (assuming your implementation is correct ... right?)

But some carriers would really like to be able to see that data in the clear -- unencrypted. This would allow them to do fancy caching (essentially, saving copies of data at intermediate points) and introduce other "efficiencies" that they can't do when your data is encrypted from your client to the desired servers (or from servers to client).

When data is unencrypted, "proxy servers" are a routine mechanism for caching and passing on such data. But conventional proxy servers won't work with data that has been encrypted end-to-end, say with SSL.

So this dandy proposal offers a dandy solution: "Trusted proxies" -- or, to be more straightforward in the terminology, "man-in-the-middle attack" proxies. Oh what fun.

The technical details get very complicated very quickly, but what it all amounts to is simple enough. The proposal expects Internet users to provide "informed consent" that they "trust" intermediate sites (e.g. Verizon, AT&T, etc.) to decode their encrypted data, process it in some manner for "presumably" innocent purposes, re-encrypt it, then pass the re-encrypted data along to its original destination.

Chomping at the bit to sign up for this baby? No? Good for you!

Ironically, in the early days of cell phone data, when full capability mobile browsers weren't yet available, it was common practice to "proxy" so-called "secure" connections in this manner. A great deal of effort went into closing this security hole by enabling true end-to-end mobile crypto.

Now it appears to be full steam ahead back to even worse bad old days!

Of course, the authors of this proposal are not oblivious to the fact that there might be a bit of resistance to this "Trust us" concept. So, for example, the proposal includes the assumption of mechanisms for users to opt-in or opt-out of these "trusted proxy" schemes.

But it's easy to be extremely dubious about what this would mean in the real world. Can we really be assured that a carrier going through all the trouble of setting up these proxies would always be willing to serve users who refuse to agree to the proxies being used, and allow those users to completely bypass the proxies? Count me as skeptical.

And the assumption that users can even be expected to make truly informed decisions about this seems highly problematic from the git-go. We might be forgiven for suspecting that the carriers are banking on the vast majority of users simply accepting the "Trust us -- we're your friendly man-in-the-middle" default, and not even thinking about the reality that their data is being decrypted in transit by third parties.

In fact, the fallacies deeply entrenched in this proposal are encapsulated within a paragraph tucked in near the draft's end:

"Users should be made aware that, different than end-to-end HTTPS, the achievable security level is now also dependent on the security features/capabilities of the proxy as to what cipher suites it supports, which root CA certificates it trusts, how it checks certificate revocation status, etc. Users should also be made aware that the proxy has visibility to the actual content they exchange with Web servers, including personal and sensitive information."

Who are they kidding? It's been a long enough slog just to get to the point where significant numbers of users check for basic SSL status before conducting sensitive transactions. Now they're supposed to become security/certificate experts as well?

Insanity.

I'm sorry gang, no matter how much lipstick you smear on this particular pig -- it's still a pig.

The concept of "trusted proxies" as proposed is inherently untrustworthy, especially in this post-Snowden era.

And that's a fact that you really can trust.

--Lauren--
I'm a consultant to Google. My postings are speaking only for myself, not for them.

- - -

Addendum (24 February 2014): Since the posting of the text above, I've seen some commentary (in at least one case seemingly "angry" commentary!) suggesting that I was claiming the ability of ISPs to "crack" the security of existing SSL connections for the "Trusted Proxies" under discussion. That was not my assertion.

I didn't try to get into technical details, but obviously we're assuming that your typical ISP doesn't have the will or ability to interfere in such a manner with properly implemented traditional SSL. That's still a significant task even for the powerful intelligence agencies around the world (we believe at the moment, anyway).

But what the proposal does push is the concept of a kind of half-baked "fake" security that would be to the benefit of dominant ISPs and carriers but not to most users -- and there's nothing more dangerous in this context than thinking you're end-to-end secure when you're really not.

In essence it's a kind of sucker bait. Average users could easily believe they were "kinda sorta" doing traditional SSL but they really wouldn't be, 'cause the ISP would have access to their unencrypted data in the clear. And as the proposal itself suggests, it would take significant knowledge for users to understand the ramifications of this -- and most users won't have that knowledge.

It's a confusing and confounding concept -- and an unwise proposal -- that would be nothing but trouble for the Internet community and should be rejected.

- - -