What kind of security professional is this Gaurang Pandya?
As far as I know it's common knowledge that both Nokia (on their Asha-series) and Opera Mini uses a proxy server to compress the data.
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."
You'll notice that the page doesn't say: "We route your banking and other sensitive personal information through our servers and are at liberty to inspect any financial transactions conducted through this phone, this process works similarly to the great firewall of China."
Many services use proxies to speed up connections, few do it with SSL, and even fewer forge their own certs.
> You'll notice that the page doesn't say: "We route your banking and other sensitive personal information through our servers and are at liberty to inspect any financial transactions conducted through this phone
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.
If part of the rendering engine runs in their servers and not in the phone, there's no chance of keeping the end-to-end encryption. Their servers need to decrypt the traffic to render it and then (hopefully!) re-encrypt it to safely deliver it to the phone. This is exactly the same as with Opera Mini and Amazon Silk.
Opera Mini is not a web browser; it can't process and render HTML+CSS+JavaScript, it only displays what the proxy servers tell it to (they do all the processing). So, you can't reasonably expect it to fetch HTTPS content and render it by itself. Especially since it's made to run on low-end phones.
There is a good chance (going on faith), that everything is fine: if they are running a secure HTTP proxy, then all of your data is safe. The only thing they would know is the IP / hostname of the site you're connecting to. Unfortunately, can't tell from that writeup if that's the case - and it's not an easy thing to test. Would be nice for Nokia to confirm, or deny...
If you put a https proxy in between, you can capture all credit card data and other sensitive information. Use something like Charles on Mac and proxy your phone traffic through it to see this for yourself. No reason to be believe anything is safe if ssl certs are being forged.
No, you missed my point. Read the article I linked. With a proper HTTP/HTTPS proxy + CONNECT handshake, you still have the full end-to-end integrity of the connection. The proxy acts as a simple TCP relay.
A simple TCP relay that can log any and all traffic passing through it at any time with no prior warning. eg. an employee with sufficient access to the server (CTO? newly hired intern? who knows) can turn on logging of your traffic and read your private communication. This includes full access to any source code you may upload to github or any transactions you may make on your bank's website.
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.
But this isn't what Opera Mini does or wants to do. It wants to compress and otherwise alter the data flowing through it, so that you get a faster experience when browsing on the mobile. To do this it needs to see the HTML, JS etc going through it. A TCP relay wouldn't be able to do that.
I don't use S40 any more, but when i did (on a 2010 C3-00, predecessor to the mentioned Asha 302), the stock S40 browser was straight webkit.
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.
The certificate images are useless to verify the claims.
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.
I am detecting a distinct lack of outrage in this thread.
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?
> 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).
> it is evident that Nokia is performing Man In The Middle Attack for sensitive HTTPS traffic originated from their phone
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.
Opera Mini and the Nokia browser are not HTTP web browsers. They are specialized clients talking to specialized transcoders.
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.
It sounds diabolical if you approach it from the direction of "what have they done to my browser sessions!?" but I think if you approach it from their development path it seems much less so.
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.
The whole freaking point of HTTPS is to prevent man-in-the-middle scenarios. If somebody does listen to your connection without you noticing it, then it's an issue of trust.
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.
Sure its terrible from the users perspective, but from Nokia's, by the time they decided it was a good idea to monkey with HTTPS, they already had the equivalent of a screen-cap trojan complete with full-on keylogger already installed. Can you blame them for the "meh" on HTTPS?
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.
An aside: Why did thenextweb's editorial designer choose the image of a guy peering darkly through what looks like a M-mount Micro-4/3rds lens adapter to occupy this article's prime page real-estate?
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.
23 comments
[ 3.8 ms ] story [ 67.1 ms ] threadFrom 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.
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.
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.
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.
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.
[1] http://www.opera.com/mobile/help/faq/#security
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.