Nokia hijacking HTTP traffic on phones?
thenextweb.com
thenextweb.com
From Opera Mini's wikipage (http://en.wikipedia.org/wiki/Opera_Mini): "Unlike straightforward web browsers, Opera Mini fetches all content through a proxy server and reformats web pages into a format more suitable for small screens."
And on Nokia developer's home page (http://www.developer.nokia.com/Develop/Series_40/Nokia_Brows...): "The Nokia Xpress Browser comprises a client and a cloud-based proxy service. When a user requests a web page the proxy reads the page, processes CSS and JavaScript code, and compresses its content, which is then delivered to the client for display on the user's phone."
Many services use proxies to speed up connections, few do it with SSL, and even fewer forge their own certs.
It says "When a user requests a web page the proxy reads the page ... which is then delivered to the client for display on the user's phone."
So if your "banking and other sensitive personal information" is a web page, then it does indeed say that.
Opera clearly states this in their FAQ[1]:
Is there any end-to-end security between my handset and — for example — paypal.com or my bank?
Opera Mini uses a transcoder server to translate HTML/CSS/JavaScript into a more compact format. It will also shrink any images to fit the screen of your handset. This translation step makes Opera Mini fast, small, and also very cheap to use. 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.
On the plus side, it may actually add security on public WiFi networks, as the connection to the Opera server is encrypted.
I always thought SSL was largely impervious to MITM attacks due to the third-party CA - in order to get around that, an attacker would need to intercept DNS requests to the CA - or even intercept IP traffic - and then pretenting to be the CA, return a forged SSL certificate. In addition to decrypting the SSL protocol by sniffing key exchanges.
Such a deliberate undermining of a secure protocol, especially the bit where they impersonate an authentication service, seems to cross some boundary of reasonable, or certainly legal, behaviour. Surely a point is reached where it is no longer acceptable to say "our intentions were benign".
What am I missing here? Where are the torches and pitchforks?
You are missing the fact that S40 "web browser" is not a web browser in the traditional sense, and plenty of HN readers know that.
Imagine that Nokia were running a VNC server with Firefox on it, and the S40 "web browser" were a VNC client connecting to that server. It's pretty obvious that Nokia would be "MITMing" your HTTPS connections in that case. This case is almost the same, but instead of VNC and Firefox they just have some proprietary stack.
edit: btw your idea of how SSL works is not entirely correct:
> in order to get around that, an attacker would need to intercept DNS requests to the CA - or even intercept IP traffic - and then pretenting to be the CA, return a forged SSL certificate
SSL clients to not connect to the CA usually, because it is not necessary to verify the validity of a certificate (due some neat crypto magic). And thus attackers won't intercept requests to CA (because there won't be such requests).
I took this statement at face value, and interpreted it to mean that Nokia was "MITMing" end-to-end SSL connections from the phone to the endpoint.
If I understand you correctly, and using the VNC analogy, in actual fact the SSL connection is being initiated on a Nokia server by a browser I am running remotely via my phone.
And while Nokia does in fact see the decrypted data coming out of the SSL pipe on their server, before they send it to the phone, this would always be an obvious consequence of running a browser to a SSL website via a VNC connection.
So the above claim is either a falsehood or at best misleading. Torch extinguished (for now).
> btw your idea of how SSL works is not entirely correct
I certainly don't claim to have any expertise in SSL, but this did surprise me somewhat. I assumed that when Chrome tells me that "The identity of this website has been verified..." that it had in fact contacted a CA and validated the cert. I might have to read up on this a bit more.
AFAIK, Chrome is the only desktop browser that supports HTTPS proxies: http://www.igvita.com/2011/12/01/web-vpn-secure-proxies-with...
It would be nice to get wider adoption for this.. Perhaps Nokia has it! :)
---
[Update] It is MITM, but for S40 browser only, which does server-side rendering:
- http://browser.nokia.com/s40-browser.html - http://www.developer.nokia.com/Community/Wiki/Series_40_web_... (look under architecture)
Same story as Opera Mini.
The employee may delete the logs after he is done, and nobody would ever know that he has accessed them. Government agencies may legally prevent anybody speaking of their wiretapping through numerous laws.
Basically, the fact that it acts as a simple TCP relay (obviously it does not, it is parsing the data) is seriously in doubt.
(The question remains if the Nokia browser does HTTP CONNECT)
Opera Mini was of course much faster than webkit if you could handle not having javascript. Nokia were pushing Ovi Browser at the time as a separate j2me app via the Ovi Store, which i guess has been rebranded to Nokia Xpress Browser and presumably bundled in current versions of S40.
From their perspective, the phone was too weak to run a full browser so they almost approached it like an XWindows session. All the work happens on their servers and the phone just collects keystrokes and taps and displays pictures. Of course they can see all of your encrypted sessions. The real browser is running on their hardware at their office. "We're the good guys, we'll keep our users' sessions private!".
What makes it muddy is that the display mechanism is a cut down browser-like thingy instead of a framebuffer. In their minds, who cares what happens to https on that section of the link; all they're doing is showing pictures... but from the users perspective? WTF did you do to my https session?!
Its decidedly suboptimal, but not quite so outrageous as it first sounds.
Maybe Nokia is not diabolical, although as any other commercial for-profit entity they care much more about their bottom-line. It isn't any different than trusting Google with your email, but for example, suppose you connect to Gmail on the web from such a Nokia device, are you prepared to have your communications available to not just 1, but 2 commercial entities?
The far bigger point however is that their servers represent a point of failure. I may trust that they won't do anything with my data, but can I trust that they are competent enough to secure their own servers? What about disgruntled employees with enough privileges? Considering how many people they fired and how bleak their future is, I'm sure they have at least some disgruntled employees.
Again, you can say this about any service. You don't know how secure a bank's servers are, right?
But on the other hand, why in the world does Nokia need to do this? A simple message informing users that SSL connections are slower should have been enough. Or at least a warning of some sorts that the connection is not entirely secure and in case you connect to your bank account you should do it from another device.
Instead, you're left with the impression that the connection is secure, when in fact there's a man in the middle who's competence is doubtful, a fact proven by the deployment of this feature alone.
If you don't have the juice in your browser-ette to run standard web, SSL isn't going to just be "slower", its not going to work at all either. But there's one thing we're in perfect agreement on. Nokia owed the users a truckload of transparency on this one. We should not have learned about it through some security researchers blog.
Assuming that the illustrations' intent was to convey the notion of scrutiny (like with a jewlers' loop or somesuch) – even if the reader buys this premise, is it the Nokia system supposed to be what is doing the peering, or some unseen black-hat?... or is it, like, an admonishment for the reader to remain observant and unblinking in watchful monocular vigilance, not allowing a single encrypted TCP packet to escape our panoptic awareness?
But it doesn't actually look like a loupe, so that's giving thenextweb's art direction a bit too much – maybe this image was meant for a review of that new EVF-equipped Leica M-system, and was used here in an innocent mix-up?
Look, I realize that the zeitgeist of “publication design“ is whatever a Google Image search turns up for an articles' keywords, but this is indicative of the cloud of editorial apathy that hangs over online publications and thwarts the evolution of a distinct visual language for the web.
Normally I try to keep my HN comments within the scope of the postings' explicit subject, but this particularly vexing example is worth the tangental note.
If there was a MITM of SSL connections it could be seen with the swap of server certificate. This is easy to check and display in an image. Failing to do so is "weird" for the less.