IETF Draft Wants To Formalize 'Man-In-The-Middle' Decryption Of Data As It Passes Through 'Trusted Proxies'

from the you-jest dept

One of the (many) shocking revelations from the Snowden leaks is that the NSA and GCHQ use "man-in-the-middle" (MITM) attacks to impersonate Internet services like Google, to spy on encrypted communications. So you might think that nobody would want to touch this tainted technology with a barge-pole. But as Lauren Weinstein points out in an interesting post, the authors of an IETF (Internet Engineering Task Force) Internet Draft, "Explicit Trusted Proxy in HTTP/2.0," are proposing not just to use MITMs, but also to formalize their use. Here's his explanation of the rationale:

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).
The "solution" to that problem is what the authors of the IETF draft -- all of whom hail from AT&T or Ericsson -- call "trusted proxies." Basically, users give permission for their data to be decrypted by an intermediate site that they trust, which would then be allowed to do stuff to it before re-encrypting it and passing it along to its original destination. The eagle-eyed among you may have spotted one or two problems with this approach; as Weinstein says:
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.
And there's another major issue. If there's one thing we've learned from Snowden it's that the NSA and GCHQ have no compunction about breaking into anyone's system. If decrypted versions of data transmissions were available on these "trusted proxies," they would no doubt become prime targets for this kind of attention. Introducing another weak link into the transmission chain would leave Internet users even more exposed to surveillance than before. Before Snowden's leaks, 'man-in-the-middle' decryption of the kind being proposed would have seemed a pretty bad idea; in the wake of them, it is just plain crazy.

Follow me @glynmoody on Twitter or, and +glynmoody on Google+

Hide this

Thank you for reading this Techdirt post. With so many things competing for everyone’s attention these days, we really appreciate you giving us your time. We work hard every day to put quality content out there for our community.

Techdirt is one of the few remaining truly independent media outlets. We do not have a giant corporation behind us, and we rely heavily on our community to support us, in an age when advertisers are increasingly uninterested in sponsoring small, independent sites — especially a site like ours that is unwilling to pull punches in its reporting and analysis.

While other websites have resorted to paywalls, registration requirements, and increasingly annoying/intrusive advertising, we have always kept Techdirt open and available to anyone. But in order to continue doing so, we need your support. We offer a variety of ways for our readers to support us, from direct donations to special subscriptions and cool merchandise — and every little bit helps. Thank you.

–The Techdirt Team

Filed Under: encryption, ietf, man-in-the-middle, security, ssl

Reader Comments

Subscribe: RSS

View by: Time | Thread

  1. identicon
    Anonymous Coward, 27 Feb 2014 @ 5:56am

    Lots of people who don't read the article here

    So many of the comments are thinking this has something to do with VPNs. It doesn't. Read the draft instead of going by third-hand information.

    This is all about HTTP/2.0, the proposed next generation of the venerable HTTP protocol.

    To those who are not following the development, HTTP/2.0 is somewhat similar to Google's SPDY, which in turn runs over TLS (also known as SSL, the cryptographic protocol behind https connections).

    Many places currently use transparent proxies for HTTP connections (transparent proxies intercept connections to the TCP port 80 used by http connections and redirect them to a HTTP proxy), on a misguided belief that this increases speed and reduces bandwidth use (it does both somewhat, at the cost of causing hard-to-diagnose problems).

    Transparent proxying is not possible with TLS/SSL without the cooperation of at least one of the endpoints, since the initiating endpoint cryptographically validates the identity of the responding endpoint. Since HTTP/2.0 is going to act similarly, transparent proxying will not be easily possible (which is a good thing).

    This draft is about making the browser send an extra header noting that the request is for a "http" resource, and specifying the negotiation between it and the MITM proxy. This is still stronger than common plain-text "http", but as others have noted it's still a step backwards.

Add Your Comment

Have a Techdirt Account? Sign in now. Want one? Register here

Subscribe to the Techdirt Daily newsletter

Comment Options:

  • Use markdown. Use plain text.
  • Make this the First Word or Last Word. No thanks. (get credits or sign in to see balance)    
  • Remember name/email/url (set a cookie)

Follow Techdirt
Insider Shop - Show Your Support!

Essential Reading
Techdirt Deals
Report this ad  |  Hide Techdirt ads
Techdirt Insider Chat
Recent Stories

This site, like most other sites on the web, uses cookies. For more information, see our privacy policy. Got it

Email This

This feature is only available to registered users. Register or sign in to use it.