Nokia: Yes, we decrypt your HTTPS data, but don’t worry about it
gigaom.com
gigaom.com
There is no MITM attack. They are not spoofing DNS or forging SSL certs. They are providing a service that users are opting in to use.
If you don't trust Nokia, don't use their phones. Even with end-to-end encryption, the data (including voice calls) is unencrypted on your phone until the software and hardware encrypts it. The maker of the software and hardware always has the capability to add eavesdropping code if they want.
It's a privacy concern as it is. Please don't muddy the waters by spreading FUD and conflating this with something it's not.
I promise I don't read your mail when I get caught.
I'm giving the first 3 months free, please provide your information below so I can get started today!
Saying it's OK to not tell someone something important because you don't respect the intelligence of the person or people it considers is well, wrong.
Also I'm very doubtful about the economics of offering a phone with a weak CPU and memory configuration. Aren't screens a big chunk of the price?
The Nokia browser is essentially a thin client that communicates with a remotely hosted web browser. The remote web browser, running on Nokia's servers, does all the complicated JavaScript and advanced CSS stuff, and converts it to a dumbed down version that can be displayed on the phone.
There clearly is a cost savings in using low-end parts. Not all screens are created equal, for example the Nokia Asha 306 uses a 240x400px resistive touchscreen. If you have ever used a phone with a resistive touchscreen you know how bad they are. It also has 32MB of RAM, 10MB of user storage, 2G data (not 3G), and no GPS. You can't run a WebKit + V8 browser on a phone with those specs, you just can't.
The BOM for a Nokia Lumia 900 (high end, with a 480x800px capacitive touchscreen) is here: http://www.isuppli.com/Teardowns/News/Pages/Nokia-900-Carrie...
It is this certificate that proves your connection is to smtp.gmail.com and not somebody else. That's the whole freaking point of HTTPS. What Google does from there, it's their business, but NO, they are not the man in the middle, as you explicitly and willfully connected to them and allowed them to send email on your behalf.
On the other hand, connecting to HTTPS with one of these Nokia phones leaves you with the impression that HTTPS connections to google.com are secure, when in fact the Nokia device is LYING TO YOU.
The example you've given couldn't have been any worst.
Here is post from the "security researcher", so you can see who the certs are issued to: http://gaurangkp.wordpress.com/2013/01/09/nokia-https-mitm/
There's a rather big difference in trusting their phones vs. trusting their services in this case:
Mobile network vendors (including Nokia's NSN) have a record of being very very helpful in supporting government wiretapping. see eg http://www.washingtontimes.com/news/2009/apr/13/europe39s-te...
This is a much bigger problem in China, etc (the "emerging markets" under discussion) than in the west.
It's much less likely they've built backdoors into the handset, and if they do they risk getting caught.
> They are providing a service that users are opting in to use.
No, there's no opting in to the violation of end-to-end security here.
http://www.wpcentral.com/nokias-xpress-browser-has-been-bloc...
I think the major issue is that you cannot 'sell' any core mobile network-devices without: http://en.wikipedia.org/wiki/Lawful_interception
So "very helpful" is kinda debatable in my opinion.
Lots of other vendors market these government espionage tools to autocratic regimes too. Eg Bluecoat, Cisco etc.
At any rate it feels bad that we have to appeal to these human rights abusing autocracies, it's not any better to have these mechanisms built into the western networks.
These phones are too under-powered to render modern web pages. It's either this or they have to view only WAP pages. If you have never used WAP on an old phone, go login to Yahoo Mail at http://wap.yahoo.com/
Overly complicated comparison would be you controlling browser on a remote desktop. Nothing has to be cracked, yet you can see data on your computer while the other computer can see them too.
[1] http://betalabs.nokia.com/trials/nokia-xpress-internet
[2] https://itunes.apple.com/us/app/opera-mini-web-browser/id363...
And yet there is confusion around it. The onus is on Nokia to educate their users that it isn't as secure as a HTTPS web browser.
You are right. And now I don't trust Nokia, after reading this news.
Well duh.
Remember how a while ago Nokia got a bit of bad press about developing the DPI technology for Iran and Egypt? (together in a joint venture with Siemens).
So they made a press release[1] about how it has come to their attention that this technology was being used for human-rights abuse (GASP you don't say?). As a result they "halted all work at monitoring centres" and promised they wouldn't do it again.
And now there is this. It is not quite as severe, but it's the very same careless attitude regarding people's privacy in contexts were this privacy really really should be maintained.
It seems pretty obvious they do not care, each time until they're caught red-handed.
So IMO, you can leave the "if" out of that statement and shorten it to "don't trust Nokia".
Shame on Opera for being part of this, too.
> The maker of the software and hardware always has the capability to add eavesdropping code if they want.
Well that's the point, isn't it? You always need to trust your hardware manufacturer that they won't do this. Developing DPI technology for oppressive regimes does not quite engender this type of trust. Nokia has to do a little bit more than just a press release before they earn that basic level of trust again (if ever).
[0] http://www.nokiasiemensnetworks.com/news-events/press-room/c...
[1] http://www.nokiasiemensnetworks.com/news-events/press-room/s...
When I access a proxy on my computer, it can't do that. If an arbitrary proxy could MITM a secure connection, HTTPS would be useless.
So I presume the Nokia browser is complicit in this scheme.
google chrome sends all my pages to translation and what-not. I have to completely trust it. that's why i never use the compiled version but the chromium one only (hence not having access to any addon via the addon site, have to do some manual work there)
Even besides the browser, how many computers don't I see the skype button next to phone numbers? would you trust skype is behaving and not sending your data to their servers? did you remember to disable this add-on for ssl pages?
A browser based on an open-source codebase with many people auditing its source-code and network traffic (there was much paranoia about Chrome when it was released). And even in that case, you have the choice to use a completely open-source browser that has a different stance on user privacy (Firefox).
An NPAPI plugin that can be easily disabled.
A third-party BOX MITM all your secure connections without your knowledge.
I don't think the above are comparable in magnitude.
On iOS this comes up after connecting to wifi as a reassuring, secure-seeming, official-looking page that pops up inviting you to accept the new certificate. Do so and boom, you're vulnerable to a MITM.
Do you trust your phone operating system? How do you know it is not capturing your data when you access a bank website? Same issue here.
The one difference is that the Nokia servers might be a bigger target for hacking, instead of hacking individual phones.
Apart from that, we already know the Chinese have hacked GMail accounts on several occasions, so Google is already a definite target and the Incidents that have been reported may be just the tip of the iceberg so far as we know.
We also know that there have been cases of corporate and government espionage in the recent past. This is happening, right now, and we may never know how extensive it is. It's entirely possible that Nokia could become a target of either technical or even employee infiltration. If so, covert access to a service like this would be a fantastic coup, especially since Nokia phones are still popular in many parts of the world with unscrupulous and technicaly sophisticated governments.
Recent mishandling of user accounts by Sony Entertainment and LinkedIn gave us a glimpse of how much damage an intrusion can cause, even though (?) their management thought their intended purpose couldn't lead to any serious liability (speaking through my hat here).
These servers probably do, as I'm sure some people use them to do online banking and shopping online.
I like Opera Mini, which is just like this. But I hope my bank blocks it.
Or a little bit more abstract, the technical security is broken and the user relies on social norms for his privacy. The same social norms which forbid my ISP to sniff my non SSL traffic.
Nokia might not even require a court order to let the government have access to your data. A court order is only to force Nokia to give access.
How do you cache without storing?
This is nothing new or special. Opera mobile browsers for older phones supported only this method of communication. It's worked for years and years. Opera Mini on iPhone does the same. Opera Mobile on Android phones and Opera for desktop have it as an option. I believe there are other tools that do this.
The second aspect is one of bandwidth. Pre-processed sites are a lot smaller than the full sites. Many people with these phones probably don't have data contracts with generous limits. And when you're paying pr byte and downloading over GPRS, every byte that doesn't have to be downloaded counts.
should google block everypass.com just because it have your banking acount password?
if i'm on a slow connection and have to use this browser to compress my connection to my bank, i will decide if i trust the browser to do so.
I just think nokia should have been even more open about this. and probably gave me an option on the browser. In that they sinned.
In this case when I go to https://www.google.com I expect that any traffic can only be seen by Google, the entire reason I typed "https" was specifically so that it was only a conversation between me and the site that I'm connecting to and no other middle men. It is of no consequence what company it is; it would be inappropriate for Google to be seeing my encrypted traffic to hotmail and it would be inappropriate for Microsoft to see my encrypted traffic to gmail.
Google continuing to serve traffic under those conditions is misleading and Google (or any other site that supports https) shouldn't allow it.
I'm ignorant of how SSL traffic is actually encrypted, but if you're already crunching the numbers to encrypt something, and a big part of encryption is eliminating redundancy, why isn't the data compressed at the same time?
Seems like you could kill two birds at once and eliminate any reason to decrypt HTTPS data for caching purposes as well. It would cut down on traffic for the rest of us on the internet too.
Or is this like CDN caching, where it's more about limiting latency than bandwidth?
Compressing and then encrypting is dangerous in a partially chosen plaintext environment like HTTPS (and Nokia is probably putting their customers at risk by doing it).
The threat is as follows: Threat model: Alice is a user on bob.com. Alice also occasionally visits HTTP websites. Eve wants to obtain Alice's bob.com cookie to gain unauthorised access to bob.com. Eve has full access to the network connection between Alice and Bob.com, and can add, delete, or modify packets as desired.
Browser software: HTTPS requests modelled as encrypt(gzip(knownText1 + queryParameters + knownText2 + secretCookie + knownText3)). By injecting a Javascript file controlled by Eve into a normal HTTP transaction, Eve can initiate HTTPS requests to bob.com using XMLHttpRequest where Eve knows the content of knownText* and fully controls the content of queryParameters.
If queryParameters contains a substring also found in secretCookie, then the overall length of the ciphertext will be shorter due to the fact that repeated substrings are compressed. When Eve confirms an initial substring of secretCookie by monitoring the length of ciphertext corresponding to a chosen queryParameters, Eve can then expand that substring in queryParameters iteratively to a longer substring until Eve has determined the entire value of secretCookie, completing the attack.
Should be obvious that it has to decrypt HTTPS to work with it at all.
Another option is the author is an incompetent idiot (news-writing-wise).
http://gaurangkp.wordpress.com/2012/12/05/nokia-proxy/
Does anyone have a reference to a law or regulation this would fall under?
Does PCI compliance apply to this situation? If yes, then Nokia is not compliant to requirement 4.1:
https://www.pcisecuritystandards.org/documents/Prioritized_A...
What assume they probably do is: Browser compress data -> Browser encrypt data for transmission to proxy -> Browser transmit encrypted data to proxy -> Proxy receive and decrypt the data -> Proxy decompress de data -> Proxy reencrypt the data for transmission to server -> Proxy transmit encrypted data -> Server receive and decrypt data
I could be wrong but, at no point are the unencrypted data transmitted over a public network. The only places the data are not encrypted is on the client, the proxy and the server.
You are already trusting Nokia party on the client side, they assumed you could also trust them on their proxy without asking you, which is moraly questionable, but surely not illegal.
EDIT: Missing step above
Of course because they're not processing the payments, there's not a damn thing the networks can do to stop them; compliance can only be enforced when there's something to turn off (your merchant account) when you're not compliant. That's not the case here.
How could they compress/optimize the pages coming to you, if they can't read it?
> To be able to do this translation, the Opera Mini server needs to have access to the unencrypted version of the webpage. Therefore no end-to-end encryption between the client and the remote web server is possible. If you need full end-to-end encryption, you should use a full web browser such as Opera Mobile.
Nokia is NOT intercepting https. The actual TLS session is run via a https proxy. No interception occurring. The guy who broke this has no understanding of the TLS protocol or PKI in general. He tried to say the root verisign certs in windows were being proof. bullshit.
its 2 TLS sessions -- or TLS in TLS proxy. No problem. Go back to sleep.
They could have turned it off for HTTPS data though, but then all the mails would not get compressed and people would have said the browser doesn't work.
>...and reiterated the point of the Xpress Browser’s compression capabilities...
Seems like they are talking about what is going on on their network between the browser and the destination.
"We" expect HTTPS to mean secure and unbroken along the way. This tells us that HTTPS might not mean secure at all. It doesn't matter what geekery is used to explain it, its not what it says on the tin.
1. Trust Nokia (or Opera with Opera-mini) and use the product.
2. Have no browser on low-end phones.
This is more a case of Nokia's product not explaining the security trade-offs to normal people. By choosing to use this browser, you are making the trade-off that it's impossible to have a secure (unbroken) connection between you and a website. Period.
There's a secure connection between the site and Nokia, and another one between Nokia and you. Nokia (or anyone that hacks Nokia) can listen in the middle since it's not a end-to-end secure connection.
| It doesn't matter what geekery is used to explain it
| its not what it says on the tin.
Everyone who says "https interception" is hard, you are right. Unless you can install arbitrary trusted root He has presented no evidence of this. All he did was sniff the wire and saw a TLS session to Nokia. It's called an https proxy, genius. Ugh. This mAkes me so mad that people believe this crap.
Sure, they should be more up front with users from the outset.
But what I'd really like to see is Nokia working more closely with app developers to help them programatically detect these connections so users can be denied more easily in apps where security is critical. Some banks jumped through hoops trying to detect and shut down WAP connections.
I would never ever use a service that decrypts HTTPS traffic. How do we know that the other side is encrypted ? For all you know, the other side of the proxy could not even use SSL for services that offer both modes (google,facebook,twitter, etc etc).
So, effective use of Xpress could be limited to articles (The Verge), magazines and mailbox use could be done through IE or through the mail app. The problem is limited on the Lumia phones but it is a bigger deal just on their S40 phones.
For Lumia it's an optional download, but then again the Lumia markets don't have to worry so much about big brother.
They did this so boneheads that sniff the traffic will see the phone to server TLS rather than having it encrypted inside the phone to Nokia TLS. That's ignorant "researcher" you actually made it easier for the bad guys now.
Excatly.
I mean if I was a bank it'd properly be in my interest to protect my customers from using a known insecure proxy (regardless of who manages it).
I don't think that's what is happening, we need further explanation. Although if that is what is happening it;s really bad as they would effectively be impersonating the sites.
It's a simple MITM attack, where the endpoint (your browser) has a whitelisted certificate for the proxy, so the browser is happy that it's talking to a correctly signed certificate that it trusts, and the proxy uses the the certificate for the other end of the connection.
http://www.paloaltonetworks.com/products/features/decryption...
It works for SSH too, if you are not careful about host keys and fingerprints.
https://www.eff.org/2011/october/amazon-fire%E2%80%99s-new-b...
And they can't even blame Android/Apple for it.
Too bad for microsoft, they bet their mobile house more or less on Nokia and vice versa.
Trust is a fragile thing.
As for the marginal gains you get from a direct SSL connection, at this stage it's been long demonstrated that the average Joe government can get their hands on CA certificates pretty easily.
So the question really is how you expected to benefit from a direct SSL connection, given the already explicit trust you have in the company to provide secure software on your device with which to make the connection?
After that said producer of my device is definitely in my 'to be avoided' category.