Bruce Schneier
Schneier on Security
A blog covering security and security technology.
« Cheating at Chess | Main | Essay on FBI-Mandated Backdoors »
January 17, 2013
Man-in-the-Middle Attacks Against Browser Encryption
Last week, a story broke about how Nokia mounts man-in-the-middle attacks against secure browser sessions.
The Finnish phone giant has since admitted that it decrypts secure data that passes through HTTPS connections -- including social networking accounts, online banking, email and other secure sessions -- in order to compress the data and speed up the loading of Web pages.
The basic problem is that https sessions are opaque as they travel through the network. That's the point -- it's more secure -- but it also means that the network can't do anything about them. They can't be compressed, cached, or otherwise optimized. They can't be rendered remotely. They can't be inspected for security vulnerabilities. All the network can do is transmit the data back and forth.
But in our cloud-centric world, it makes more and more sense to process web data in the cloud. Nokia isn't alone here. Opera's mobile browser performs all sorts of optimizations on web pages before they are sent over the air to your smart phone. Amazon does the same thing with browsing on the Kindle. MobileScope, a really good smart-phone security application, performs the same sort of man-in-the-middle attack against https sessions to detect and prevent data leakage. I think Umbrella does as well. Nokia's mistake was that they did it without telling anyone. With appropriate consent, it's perfectly reasonable for most people and organizations to give both performance and security companies that ability to decrypt and re-encrypt https sessions -- at least most of the time.
This is an area where security concerns are butting up against other issues. Nokia's answer, which is basically "trust us, we're not looking at your data," is going to increasingly be the norm.
Posted on January 17, 2013 at 9:50 AM • 43 Comments
To receive these entries once a month by e-mail, sign up for the Crypto-Gram Newsletter.
maxCohen • January 17, 2013 10:08 AM
"Nokia's mistake was that they did it without telling anyone."
How are users supposed to know that the other companies are "telling" people they are doing it? If a site I go to is HTTPS I don't expect a company to do a man-in-the-middle attack for any reason.
moo • January 17, 2013 10:17 AM
Most corporate workstations already route their web traffic through a proxy, and already have trusted certificates signed by that corporation. HTTPS sessions are often MITM'd by the proxy so the corporation can make sure their sensitive info isn't being leaked, porn isn't being surfed, etc.
Most users would be surprised though, to learn that their "secure" connection to their bank's website, or whatever, is actually fully readable by their company's IT department.
Otto • January 17, 2013 10:17 AM
All the network can do is transmit the data back and forth.
That is all the network should ever do. The moment that it tries to do more than that, then the network is no longer trustworthy.
Michael • January 17, 2013 10:24 AM
Perhaps we need to redefine this activity...MitM "attack" may be inaccurate where this automated process takes place. Technically it's not even a vulnerability...the piece missing here was simple awareness.
B. Johnson • January 17, 2013 10:27 AM
Am I understanding this correctly? This works because the software on Nokia's phone invisibly defaults to trusting Nokia's server's certificate which is provided to it instead of the destination site's? If the phone's browser was "honest," this wouldn't generally be possibly, right?
Hauke • January 17, 2013 10:27 AM
They can't be rendered remotely.
What? That is exactly what Opera and Nokia do - the HTTPS session endpoint is their server, the local browser is only for displaying a simplified page and for catching user events. The "browser" (Opera mini at least) only renders, it is not responsible for the connection like a traditional browser is.
Ok, a little bit of rendering is still involved on the client side, it is not an image that is transferred - but it is not the full page source, only a simplified version, maybe even in a proprietary format.
PatrickAK • January 17, 2013 10:47 AM
Does the process of "pinning" re certs that some web browsers use prevent this sort of MITM attack?
maxCohen • January 17, 2013 10:56 AM
@moo You're right, people would be shocked. Just like thinking Tor will keep you safe from the desktop through your company's network.
Dan • January 17, 2013 11:02 AM
It would be nice if the infrastructure could get to the point where it's not perceived "necessary" to do this in order to obtain reasonable performance...
Jeff H • January 17, 2013 11:04 AM
As others have pointed out, IT departments regularly do this by installing a trusted root certificate from their proxy. I'm not sure I trust my IT department (sorry guys) any more than Nokia to keep secret stuff secret. I bet there's caches that could be scraped or leaked.
However, the original source, gaurang, appears to state that Nokia have patched the browser to no longer perform the attack, instead tunneling HTTPS over HTTP.
moz • January 17, 2013 11:05 AM
@maxCohen
There are lots of uses for HTTPs which are not totally critical. If you have a bank account with only a few hundred dollars and no possibility of a loan, then why not use it via a proxy service? MiniOpera is completely okay for this.
On the other hand, if you have a list of husbands of policewomen who are victims of domestic violence that you need to send to your partner so he can protect them, you might decide that you shouldn't send it via a server where the police can get automatic access. The polices of a normal web browser would be okay for this.
Nokia was lying and misleading people. It makes you wonder who has taken over there.
ahminederpajerp • January 17, 2013 11:09 AM
Nokia also provided Iran with their centralized telecom turnkey spy system. Don't worry trust us with your data
kashmarek • January 17, 2013 11:26 AM
They are all looking at your data. None of them can be trusted.
Lyle Ability • January 17, 2013 11:26 AM
Don't most banks, etc have a terms of service clause where they aren't responsible if you freely give out your login information? This is essentially what is happening if you are mobile banking with NOKIA, correct? You would be consenting to let NOKIA have access to your login information, thus negating liability for a lot of sites.
I'm going to bet that NOKIA isn't assuming that liability either.
Jay • January 17, 2013 11:31 AM
Without having much detail on how the MITM / proxies actually work on these phones, I'm a little more worried that another malicious process running on the phone could use this feature to steal information from the user's secure session.
Maybe this scenario is a little speculative, but I am thinking of that case a few years ago in Greece where malicious actors exploited the built-in CALEA-type wire-tapping features of the cell phone system to access "secure" communications. The wire-tapping capabilities were thus, in the system by design and turned out to be critical vulnerabilities.
Peter A. • January 17, 2013 12:00 PM
That's OK for an employer to MiTM SSL sessions once it tells its employees beforehand. It's another matter when a telecommunications carrier does that, telling or no telling. Carriers should carry traffic - that's what they are paid for, not for meddling with it.
If one wants to optimize their traffic, fine, he/she may install Opera Mini or whatever and trust the intermediate servers not to leak his/her banking activities or some even more private transmissions.
Chris • January 17, 2013 12:09 PM
Our IT department performs HTTPS interception to facilitate web filtering and malware inspection. It's very transparent, but also clearly disclosed (and verifiable) to the users: the appliance has an internal CA which is trusted by corporate workstations, which it uses on-the-fly to generate certs for sites the users are visiting. Anyone inspecting the certificate they receive for an HTTPS site will clearly see it was generated internally. Certain categories of websites are specifically exempted from interception for privacy reasons - financial & banking, health, etc. - and for any of those sites you can see that the certs are signed by their original CA. Intercepting & logging data at the appliance wouldn't be impossible, but it's not an inherent function - you'd have to work at it.
maxCohen • January 17, 2013 12:45 PM
My question is how are people being told? If it's in the Terms of Service, give me a break. It shouldn't be done in the first place.
martinr • January 17, 2013 2:16 PM
What Nokia has been/is doing is clearly and undoubtedly a crime in Germany for which they face a prison term of up to 5 years or a monetary fine.
"Telling their users what they're doing" will not do help them in any way. Strange concept that it could. Are there really legal systems where a bank robber that admits the crime he is commiting "This is a bank-robbery, I am taking all your money", will make it impossible to prosecute and convict him for bank robbery??
If Nokia (any anyone else committing such crimes) is not making it a true "opt-in" offer, and stays clear of everyone who doesn't opt-in, then what they're doing will remain to be a criminal offense.
Jason R. • January 17, 2013 2:17 PM
@moo & @Peter A.:
We tell our users all phone calls are logged (and for certain jobs like CSR, Dispatch and Power Scheduling, recorded for legal/financial reasons). We block all chat as well, because until we have a technical method to archive it all and respond to legal requests for it, we aren't going to be held liable for allowing it.
We also tell them that all computer usage is monitored. Personal usage is allowed, but should be kept to a minimal. The tech savvy ones know we MitM all SSL traffic. Anything they want kept private, they use their smartphones for.
One thing we do (as IT staff need to take care of personal items at work) is why do not MitM certain specific types, like banking, health care, and union websites. Why? Because it seems like a good balance for privacy for personal items that often can't wait until after work.
Anonymous • January 17, 2013 2:41 PM
Practically, is it possible to set up your browser to avoid or complain about these MITM attacks today? When I talk to my bank can I somehow validate that I have their certificate? ( Please forgive my inaccurate usage of terminology.)
mike acker • January 17, 2013 2:55 PM
PGP, WinZip (others?) -- compress the data first and then encrypt it so the compression argument is bogus.
second, as i've noted often eleswhere every user needs to acquire PGP or GnuPG capabilities and attend to their own authentications . i think the procedure for this is already established -- known as https 2-way authentication -- which is an exchange of keys requiring both ends of the link to authenticate
done properly it is my computer that provides the service with an encryption key. if you understand PGP(GnuPG) you see then that a MITM or proxy cannot read the traffic -- unless -- my computer is compromised so that they can steal my private key and private key password .
most of the stuttering we have going on about security is based on a lack of understanding of how PGP(GnuPG) keys are protected -- and -- the disastrous effect of malware . no discussion of encryption is meaningful until the questioon of malware is first resolved .
Clive Robinson • January 17, 2013 3:06 PM
From what I remember DangerOS used on the likes of the Motorola SideKick phone effectivly did similar by actually being a "thin client".
The thing is,
A) Why are people surprised at this?
B) Why do they assume that their systems are secure just because they use HTTPS?
How many times have we talked on this site about malware that does an "end run" around the browser SSL?
You could argue that using a thin client that is strongly locked down with a server which is properly and timely kept uptodate is more secure.
I think for the purposes of this particular thred we should make a distinction between IT security and User Privacy, because what is upseting people is the lack of Privacy not the platform security.
Henning Makholm • January 17, 2013 3:15 PM
Is it really a man-in-the-middle attack on the SSL protocol? It sounds like the case is "just" the the built-in browser software happens to offload the protocol implementation to Nokia servers somewhere in the cloud.
If so, the the man is not in the middle of anything; he is your trusted cipher clerk.
nHunter • January 17, 2013 5:40 PM
Chris,
Your statement that “Anyone inspecting the certificate they receive for an HTTPS site will clearly see it was generated internally” seems problematic. What do you mean by “the” certificate? A banking website could be loading scripts, images, etc. from multiple domains, and no browser I’ve seen makes it possible to control or even see (clearly or not) the trust relationships involved.
(Firefox will sometimes pop up a dialog saying “this page includes insecure content”, if it includes anything from a non-HTTPS site; but only after loading it, which is completely braindead. The only option is to hide the warning—there’s no way to lstop it from loading.)
Will browsers even notice the trivial case where your bank’s login page is secured by the proper CA, but when you reconnect to send the password, the MitM CA is used? (Even if you notice, it’s too late.)
moo • January 17, 2013 6:12 PM
@Henning Makholm:
Yes, its a MITM attack, because the user thinks they are establishing an end-to-end-secure SSL connection with their bank, but really they are just connecting to the corporation's proxy, which is establishing its own SSL connection to the bank. The proxy decrypts all traffic coming from one end, and re-encrypts it for the other end with the other key, its a textbook example of MITM. Even though its theoretically detectable by the user if they carefully inspect the security certificates, almost no users actually look at those things.
John David Galt • January 17, 2013 7:04 PM
The real problem here, I believe, is not limited to https: but to SSL generally: as implemented on most consumer-level systems, SSL is set to trust a huge list of "authorities", a list which includes the spy agencies of some pretty bad countries (as well as some quite corrupt commercial certificate issuers). EFF has written about this repeatedly and is working on solutions.
Jay • January 17, 2013 8:02 PM
Every time I hear about this (including the corporate-network equivalent), I wonder about the UI.
The client's going to see the proxy's certificate, and is never going to see the certificate that the proxy is accepting.
So how on earth does this work for a self-signed certificate? (And its slightly more legitimate cousin, the one-day-past-expiry certificate?)
Does it just disable certificate pinning? (Or worse, pin *to the proxy cert* and still not add any security for the end user?)
What about EV certificates and the magic "green bar"?
Given how many security problems can be attributed to UI, futzing with the origin information the user sees seems like a disaster waiting to happen...
Adrian Lopez • January 18, 2013 12:45 AM
"With appropriate consent, it's perfectly reasonable for most people and organizations to give both performance and security companies that ability to decrypt and re-encrypt https sessions -- at least most of the time."
It seems to me that, compared to a system with end-to-end HTTPS encryption, this kind of system is only as secure as the MitM's own network and computer systems, and just as trustworthy as the people who have access to them.
Mirar • January 18, 2013 3:39 AM
If the whole point of the product is to run the (traffic-minimizing) browser in someone else's cloud --
-- you shouldn't really be surprised that they can snoop on your data.
It's not MiTM if you told someone else that they can be Alice for you.
Having worked a lot on cell phones from a security and mobile malware level (at one of the ma bell babies and at a major phone vendor)... no, they do not need to be interpreting that data, lol.
What they do "need" to do is work with international phone companies who demand changes from them. Yes, China included. All those yummy countries who telephone systems have no connection WHATSOEVER with their government or spying. :/
Because what does telephony tech have to do with spying? Spies are in tuxedos in embassies and planting bugs in everyone's house. They don't care what anyone says on the phone.
Not saying that is a conspiracy, just saying, "Hey, why do they need to sneak into SSL to do this work".
Yes, there is an "opaque" problem with phones -- you *have* to watch the data upstream to protect the end users and the overall phone network. No choice about that. Yes, SSL decoding can help on that, to detect signatures -- upstream.
But you also have to be able to break SSL in order to comply with government requests to spy. Period. Not just one government, but all the big ones with money to throw around.
Me
(LOL, sorry, ludricous nick I just thought up. :-) )
ManxStef • January 18, 2013 7:04 AM
No mention of SPDY? Google designed the protocol to address most of these shortcomings.
Vles • January 18, 2013 9:13 AM
Nokia's mistake was that they did it without telling anyone.
Golly, deja vu here...
- "If it did it without your permission it would be evil to do good?"
- "If I don't know I'm being screwed, then I'm not unhappy"
- "Is trust added at the cost of some liberty?. However, since we didn't ask for it in the first place, one can argue we are set up with a "dishonest transaction"?"
http://www.schneier.com/blog/archives/2011/06/...
---
Knowing that we use control to encapsulate trust one must first argue whether trust flows from control or the other way around?
And if one takes up a position that Control flows from Trust, it stands to reason that:
1. it is impossible to ever Trust anything that enters a computer from the Outside
2. computers should only ever be used for the single purpose they have been designed and developed in the first place: as a calculator.
hah!
moo • January 18, 2013 9:21 AM
Off-topic (where's our squid post? :)
"TSA officials said the agency has canceled its contract with the company [RapiScan] because it had failed to deliver software to protect the privacy of passengers."
David Leppik • January 18, 2013 11:30 AM
@nHunter:
There is no good reason why it's necessary for a bank or any other website to be remotely loading content for an HTTPS page. Sure, there may be a few bad or lazy reasons, but it's perfectly possible for the bank's server to provide all the necessary content, either by hosting it or by acting as a proxy (with URLs changed.)
Vles • January 18, 2013 12:32 PM
Off-topic (where's our squid post? :) -- new year new totem?
Google Declares War on the Password
http://www.wired.com/wiredenterprise/2013/01/...
There's talk about access tokens such as USB sticks or even rings....ah J.R.R. Tolkien would approve of the rings....
Legal • January 18, 2013 2:00 PM
My question is:
What is Nokia'a legal liability for deliberately causing data breaches per certain regulation - in particular, should any U.S. user have used their Nokia MITM'd browser to transfer Protected Health Information, the U.S. HITECH act requires such information to be rendered unusable, unreadable, or indecipherable to unauthorized individuals (http://www.hhs.gov/ocr/privacy/hipaa/understanding/coveredentities/federalregisterbreachrfi.pdf). This includes medical, dental, vision, health savings account, and other health care related data.
As no-one at Nokia was an authorized individual in most cases, and they deliberated took data that had been rendered indecipherable and make it decipherable again, this seems an interesting legal avenue to pursue, both on the face of it, and to attempt to put forth into the various conversations some manner of legal consequences for this type of behavior.
I know many European countries have strong data protection/privacy laws - can Nokia's local divisions there be sued as well?
BlueRaja • January 18, 2013 2:22 PM
FYI this is what Amazon does with the Kindle Fire. The only difference is, they've admitted to it from the start.
nHunter • January 18, 2013 5:17 PM
David wrote:
“it's perfectly possible for the bank's server to provide all the necessary content, either by hosting it or by acting as a proxy”
Is that actually common? TD Bank in Canada, for example, bounces users between several sites—tdcanadatrust.com redirects to td.com for the login page, then to another domain after login, yet another for their brokerage; and the brokerage redirects to “bonddesk.com” (?) if the user clicks the ”bonds” tab. Citibank apparently sets up load-balancing such that clients get a different cert (one of many valid certs) each time they log in.
Who’s doing this right? Ideally I’d set up my banking browser profile to accept exactly one cert and disable unencrypted protocols, but it seems totally impractical.
Euripides • January 19, 2013 7:20 AM
Anybody surprised? Nokia has to do this to comply with the ETSI standards.
S.Alainen • January 22, 2013 1:05 PM
99.9% of people who disagree with this type of caching and pre-rendering are not relying on cheap feature phones with small low resolution screens and unreliable GPRS connections for their ONLY internet access.
Jason • January 25, 2013 7:24 PM
So is this article saying, for sure, that HTTPS use a useless protocol for an end browser?
Can someone up the chain simply have a copied cert as your browser and then decrypt your data?
If that is so, then all security from end-to-end is entirely unreliable as your ISP or company can have a cert? What is gong on here?
Wilson • January 30, 2013 7:27 AM
I was recently told about the same thing done by ISP via private key leaked from CA (so the MITM can sign false certificate as trusted).
It seems to me that this is too strange (or too big) not to be a hoax, but now I'm not to sure...
Subscribe to comments on this entry
Post a comment
Schneier.com is a personal website. Opinions expressed are not necessarily those of BT.
|
| Subscribe |
Subscribe via Kindle |
| Blog Menu |
SearchPowered by DuckDuckGoBlog Home Page
Archives by Date2013 J F M A M
Tags  |
| Latest Book |
more books by Bruce Schneier |
Comments