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 identi.ca, and +glynmoody on Google+
Filed Under: encryption, ietf, man in the middle, security, ssl
Comments on “IETF Draft Wants To Formalize 'Man-In-The-Middle' Decryption Of Data As It Passes Through 'Trusted Proxies'”
This is sheer insanity. I’m comfortable in giving up efficiency to keep my data between me and my target server.
Speaking of which…
They who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. – Benjamin Franklin
Now on the Internet! (replace freedom with privacy and safety with efficiency for added fun)
Re: Re:
“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).”
“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.”
This is a bunch of nonsense. Encryption and decryption is a processor intensive task. If they are decrypting and re-encrypting everyone’s data that’s not introducing efficiencies, that’s just making things more inefficient.
I wouldn’t be surprised if commercial release to malicious exploit took under a week.
Next, an ISO standard for anal probes !
Such a system would also make it difficult to bypass government filters, especially as this would allow them to view traffic over VPNs. The MAFIAA will love this capability.
Not getting it.
Do they not understand the purpose of the encryption between two points? It’s to keep out exactly this sort of behavior.
What they are proposing… the days may as well not be encrypted.
Re: Not getting it.
*data
Re: Not getting it.
You’re assuming that that isn’t the intent.
I’m inclined to believe malfeasance is involved here.
Olympics in stupidity?
Wow, did someone start a “let’s make the most stupid internet standard ever” competition? Because this one certainly looks like a worthy opponent for Berners-Lee’s DRM-is-great stunt…
Re: Olympics in stupidity?
This is probably primarily for money transactions where banks and governments would like to avoid having too much money end up in tax havens and to better be able to fight black markets. The question is if they can avoid it becoming the default standard for other purposes. Both exclusively cladestine or IP-related uses will be very uncomfortable for “free speech” (whatever that is!).
Re: Re: Olympics in stupidity?
you’re so cute in your innocence…
as if unka sugar is really targeting rich folk, etc who take advantage of all these grey/black areas of transactions, etc…
just like the banks that ADMITTED to money laundering got prosecuted ? ? ?
oh, wait, didn’t happen…
you know all the zillions of dollars of illegal drug money floating around ? you do know where it gets laundered at rates of 30-75% ? the banksters, right ?
(yes, that is correct: you take the bank $1 000 000 in drug money, and you will receive 250 000 back of ‘clean’ money, nice work if you can get it…)
now, since we KNOW that IS where all the drug money gets laundered, you’d figure it would be really easy to surveil and catch those crafty banksters, wouldn’t you ? ? ?
gee, i can only wonder what the explanation is for why 99.99% of them NEVER GET INVESTIGATED, much less prosectued, much less jailed…
can you guess why that is so ? ? ?
(hint: you will not find that info in the lamestream media, this is deep political stuff that is NOT talked about on the sunday shows…)
Re: Re: Olympics in stupidity?
You’re not thinking anywhere near big enough or creatively in scope.
I have no problem with this. Just as long as I run the trusted proxy servers. Do you realize how much money I could make off of people’s bank information alone? (FYI to the NSA: I don’t plan to steal your job)
And if there’s two things we’ve learned from Snowden, the second thing is that after NSA & Co. break into a system, they leave it wide open and vulnerable to hacking by anyone who knows about the vulnerability.
And if there’s three things we’ve learned from Snowden, the third thing is that the NSA’s lists of exploitable vulnerabilities aren’t hard to acquire.
soooo
to defeat this you use a NON trusted VPN/proxy that they have no idea is actually trusted to you….
HA stupid peons get a life….the key wilbe to set you and your friends up with such and as the EU and south america build there own backbone to by pass the usa you will begin to see less and less requirement of americans period
better get those embedded cia agents setup now and those nsa spy hills in those nations going now, we got to worry bout dem twerrorists
Re: soooo
Yup – it only happens in murica, amirite?
I don't trust anyone
Basically, users give permission for their data to be decrypted by an intermediate site that they trust
So since I don’t trust any of them, will they leave my traffic alone? I think not!
Defenses?
So… how would we protect ourselves?
If an ISP does this, the security-conscious users flock away to ISP’s they can trust, if any. If all available ISP’s are compromised, then… you’d have to get your VPN encryption key through non-electronic means to ensure no one is pretending to be your privacy-provider. Is postal secrecy still a thing?
Any better solutions?
Re: Defenses?
Vote in the pirate parties and let them roll back the governments of the world, and rein in the big corporations. Of course this may be a problem.
Re: Defenses?
That’s actually pretty easy — don’t use their VPN servers and treat their SSL & HTTPS connections as unencrypted.
“you’d have to get your VPN encryption key through non-electronic means to ensure no one is pretending to be your privacy-provider.”
No, you really don’t. The mechanism for dealing with key exchange over untrusted connections is built into all the major PKE systems. You just have to use them (which most people don’t).
What this really emphasizes is that encryption can’t safely be made automatic and invisible to the end user. It never could, but everybody was willing to play pretend and accept reduced security in exchange for convenience. This just calls out that practice as a terrible one.
Re: Re: Defenses?
Do you mean that it can’t be done at all, or that it can’t be done with the current CA-infrastructure and browser mess.
I posit that it security and privacy can be had without any brain activity from the end user.
plug: eccentric-authentication.org
Re: Re: Re: Defenses?
“I posit that it security and privacy can be had without any brain activity from the end user.”
If you have a way to do it, then good for you! You’ll be a billionaire. Your site doesn’t actually explain how this is accomplished, though, so it’s impossible to tell if you found the holy grail of security. From the sparse details you’ve given there, I can think of a number of security problems, though — but it’s hard to say for sure since I couldn’t find an actual description of the implementation.
Security and privacy cannot be had without inconveniencing the user so far, and I see nothing on the horizon that indicates this will change anytime soon.
MITM attacks are illegal, except when they are not.
It is ok when I do it, but you will suffer consequences – because.
What a surprise, more companies want to install an intentional security vulnerability in the name of convenience…
Re: Re:
Naw, not convenience. not bandwidth reduction either, and certainly not to enhance the end user experience, although they’ll pay lip service to that when they explain why they want to charge you an extra $5/month for an “enhanced, accelerated web browsing experience”.
Systems at Telco scale tend to be too complex and expensive in terms of maintenance and integration to be convenient for the telco.
The Telco’s will only implement this in exchange for the enhanced ability to monetize your traffic. Traffic stats will be sold at various tiers and levels of granularity to anyone with money to buy – marketers, government agencies, divorce lawyers, politicians, law enforcement, etc. And most folks in the public will pay extra each month for this benefit.
Re: Re: Re:
The Telco’s will only implement this in exchange for the enhanced ability to monetize your traffic.
Exactly, it makes it more convenient for the ISP.
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.
Re: Lots of people who don't read the article here
Actually proxies are more than just for speed and bandwidth, but also to enforce security policies. Think of it as a cheap DPI solution specialized for web traffic.
IE. If company X wants to ban facebook.com and log all attempts to reach it, they can easily place a squid proxy to intercept those attempts and redirect them to walled garden page.
Last time I used a MITM was during the PS3 debacle with Linux. A quick proxy server between my PS3 and Sony’s server to decrypt SSL traffic between my console and them and post results to developers working on alternative firmware.
So point being, it’s a tool and like every tool can be used for both good and evil depending on how you look at it.
More clarification, and concerns
AC @ nr. 16 is basically right. HTTP 2 will have TLS by default, and so something like this would be necessary for proxying. The argument for it is actually stronger than AC @ post 16 concludes, tho.
With HTTP 1.1 (current standard), ISPs can proxy, and there is no shielding of data from *other* intermediaries either. With HTTP 2 and this proposal, ISPs could proxy, but data *would* be protected from *other* intermediaries (those which lack suitable certs, anyway). Thus it is in a strict sense better than HTTP 1.1 (tho it is worse than HTTP 2 without proxying, if you value data security over speed).
My concern is that the “consent” to this will not be a real choice for users, but instead will be required as a condition of internet access.
Re: More clarification, and concerns
It seems the key concern is whether the user will be able to choose what kind of connection to use upon following a particular link, as is the case for http vs https links. There needs to be a clear distinction between secure connections and connections involving a trusted proxy, including prominent and unambiguous indications by the browser. Otherwise it becomes a question of fooling users into thinking the connection is more secure than it truly is.
As some commenters have noted this is a lot less about MITM attacks than it is about transparent proxies. And there are already solutions that solve this problem, they are just in a layer above the protocol so are expensive from a processing standpoint.
In order to implement this the proxy manager would have to have admin access to the OS to configure the trusted prox. Unless ISPs make this mandatory to use their systems (unlikely) it shouldn’t affect public users that much. And if ISPs do make it mandatory then almost everyone would freak out since it would compromise SSL universally including SSTP/SSL VPNs and banking sites. If you think Bank of America is going to allow lesser companies to increase the risk on their books you haven’t been paying attention.
Re: Re:
“As some commenters have noted this is a lot less about MITM attacks than it is about transparent proxies.”
It is both — it’s a way of enabling transparent proxies through the use of a MITM attack.
The inclusion of this mechanism, in my opinion, completely destroys the point of HTTPS unless it is opt-in only and the end user (not the web server) is the only one who can make the opt-in decision. Even if those things are true, it dramatically reduces the point of HTTPS.
The only rational thing to do if this is included is to treat HTTPS as if it were plain old HTTP.
how long until somebody comes up with a VPN system that uses a second encryption of a different kind within the SSL encrypted packets?
I would propose to call it the “fuck you protocol”
Re: Re:
This is trivially easy, and commonly done, right now. The obvious way is to tunnel SSL connections through SSL connections.
something just occurred to me.
could this be just formalizing what they already do for the NSA?
Remember the IETF drafts many things that aren’t used in the public internet. A standard for SSL inspection would help organizations who want to monitor their employee usage, like mine does. I currently manage a device that intercepts SSL connections from our employees to internet sites. We do this because we’re required to prevent and detect data loss (we deal in PHI). Don’t go all alarmist over an IETF standard until it gets used in ways which actually go against your beliefs. I don’t want this on the internet at large, but it does/would have legitimate uses, and I’m interested to see what comes out of this draft because the current SSLbump technology sucks quite a bit.
Re: Re:
“I currently manage a device that intercepts SSL connections from our employees to internet sites.”
Good luck with that. 🙂 I understand why companies do this (regulatory issues), but it’s a waste of time and money. I’ve yet to see such a system that isn’t easy to bypass, and the prevalence of smartphones means that users don’t even have to use your network (or MITM system) at all.
Re: Re: Re:
The only way to bypass it is to go off network, and we have other tools in place for that. We use WCCP instead of a configured proxy.
Re: Re: Re: Re:
Without some kind of exploit or back door, how exactly would you intercept off-network traffic?
Re: Re: Re:2 Re:
We use a layered defense, leveraging other monitoring tools. There are a handful a few different solutions for DLP and insider threat management software for tablets/phones/computers that we utilize.
Re: Re: Re:3 Re:
I don’t know what this means. I presume you’re being intentionally opaque, so I’ll just invite others to address the likelihood of your being able to monitor and/or intercept internet traffic in a “bring your own device” context.
Re: Re: Re:4 Re:
The likelihood is nil. I believe he’s talking about people who use their smartphones and whatnot on the company’s network, which no sane person would do.
If they really are intercepting cell traffic, they’re in violation of a number of laws.
Re: Re: Re:4 Re:
We don’t allow BYOD. Any reasonably detailed explanation of our posture would be pages long and I doubt anyone would want to read it. I’m not attempting to be opaque, I just don’t want to shill for specific products. Insider threat monitoring, data loss prevention and SSL inspection is served by a pretty narrow field of vendors, though.
Effectively, all company assets are closely monitored at the network and endpoint level. We have several pieces of agent software to provide DLP and insider threat protection regardless of where in the world/internet a person is.
Re: Re: Re:5 Re:
Note that the company provides all the equipment we monitor, phones, tablets, what-have-yous.
There are, of course, ways around any technical controls. As another poster said, they will eventually be caught if they do something outside of policy, but its pretty rare. Our major security concern is that our data doesn’t leave the organization, not what people say in private emails sent during work hours.
Our users sign several pages of employment agreements where this is spelled out. We’re not doing any monitoring without user knowledge and consent, as might be done by government agencies or less-than-ethical people. We have a pretty stout set of requirements that must be met before the gathered data is unlocked. Pretty much like I would have assumed the government would have had (but now I know better).
We’re quite serious about protecting privacy and the business. My major concern during implementation was privacy. I’m opposed to being monitored and monitoring others, however I’m also opposed to not having a job next week because Health and Human Services hits us with a gigantic fine that shuts our doors or gets us sold to a competitor.
Re: Re: Re:3 Re:
I have a bootable harddrive with an operating system on it and my cellphone has 4G tethering.
I can plug in the harddrive, boot to my OS and tether to my phone.
Can your systems detect this?
Legitimately curious, not trying to sound pretentious.
Re: Re: Re:4 Re:
I can probably configure a bios to where you can’t boot from CDRom without having an admin password allowing you to reconfigure the BIOS.
But here’s the thing: There are multiple tiers of controls. When the security officer catches you doing this with a corporate owned workstation in violation of company policy, your next stop is going to be HR.
Willful violations of corporate policy is generally considered to be an instafail by HR types, and you will end up on the losing end of that discussion. And you’re not going to be successful in arguing that you “accidently” violated corporate policy by downloading a live image, burning it to disc, and reconfiguring your computer to boot from it so that you could browse porn from your desk.
Now, you might not get caught – right away. But if you’re working in an organization along the lines of what I believe AC is describing, you will eventually get caught.
Re: Re: Re:4 Re:
If they?re really paranoid, they may have locked all their cases and epoxied any external ports, plus disabled booting from CD and USB and password-protected the BIOS.
If they?re using a USB mouse or keyboard, you could possibly take the keyboard apart and attach a USB port, but even that could be easily foiled with software to restrict USB device classes or serial numbers ? or by using PS/2.
Re: Re: Re:
John: Yes, such systems are often trivially bypassed. And boy, does HR tend to get pissed when they catch you doing it, as you’re demonstrating that you’ve gone out of your way to violate company policy.
Re: Re: Re: Re:
I am well aware. 🙂 I work in a high-security environment (for a security company) myself.
My point is this: almost every here does their web browsing/emailing from their smartphones, bypassing the company systems entirely (only managers actually do the BYOD thing — nobody else trusts it), so the controls the company has in place — very similar to yours, I’ll bet — are largely irrelevant. It was really just a snarky side-note, not a criticism.
Re: Re: Re:2 Re:
John:
Fair enough. I missed the snark – all too often I come across folks of the “but it was trivial to bypass, why am I in trouble” mindset who legitimately don’t seem to get what happened.
Typo/Missing word
all of whom hail from AT&T/NSA or Ericsson
‘Trusted proxy’ that decrypts data, seems to defeat the whole purpose of end-to-end encryption. The fact that AT&T are the authors of this man-in-the-middle proposal, makes me even more suspicious.
Mobile phone carriers have already tried carried out man-in-the-middle attacks in the past. Nokia releasing their own web browser named “Xpress Browse”, which allowed them to eaves drop on all end-to-end encrypted communications.
“Nokia Running A Man In The Middle Attack To Decrypt All Your Encrypted Traffic, But Promises Not To Peek”
https://www.techdirt.com/blog/wireless/articles/20130111/03432221640/nokia-running-man-middle-attack-to-decrypt-all-your-encrypted-traffic-promises-not-to-peek.shtml
If I’m going through all the trouble of encrypting my end-to-end communications. I’m expecting those communications to remain secure, private, and confidential all the way to it’s final destination.
We already know the NSA has tried, and succeeded, in influencing NIST encryption standards. What’s to stop us from believing this isn’t another attempt to influence and weaken IETF standards, so the NSA/GCHQ can continue to easily eaves drop on mobile phones.
These ‘trusted proxies’, sound like a trojan horse, and ripe for abuse. What’s to keep the mobile phone carries from ‘spoofing’ the ‘trusted proxy header’ in http 2.0? Effectively enabling ‘trusted proxy’ without the customer’s permission.
This whole proposal is ‘insecure’.
Yet another layer,
Coming up next: SSL over SSL.
The thing is, the draft proposes something different, it goes into more detail here:
http://hillbrad.typepad.com/blog/2014/02/trusted-proxies-and-privacy-wolves.html
It’s still silly, coz it’s effectively crypto-snake-oil, but not as sinister.
When?
When did IETF become a branch of the NSA?
But some carriers would really like to be able to see that data in the clear — unencrypted. This would allow them to do whatever they want.
Of course, the authors of this proposal are not oblivious to the fact that there might be a bit of resistance to this “Spy on us” concept. So, for example, the proposal includes the assumption of mechanisms for users to friendly opt-in of these “trusted spy” schemes.