

Nokia hijacking HTTP traffic on phones? - kyberias
http://thenextweb.com/insider/2013/01/09/nokia-seems-to-be-hijacking-traffic-on-some-of-its-phones-grabbing-your-https-data-unencrypted/?fromcat=microsoft

======
brunnsbe
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...](http://www.developer.nokia.com/Develop/Series_40/Nokia_Browser_for_Series_40/)):
"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."

~~~
fleitz
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.

~~~
skrebbel
This is exactly why my bank blocks out Opera Mini. Which is excellent of them.
I use Mini for everything except banking now, and it works like a charm

~~~
mqzaidi
But if Nokia can go to the extent of forging SSL, what stops them from using a
different User Agent and pass through the block?

------
antoncohen
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.

[1] <http://www.opera.com/mobile/help/faq/#security>

------
smegel
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?

~~~
zokier
> 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).

~~~
smegel
> 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.

------
igrigorik
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...

AFAIK, Chrome is the only desktop browser that supports HTTPS proxies:
[http://www.igvita.com/2011/12/01/web-vpn-secure-proxies-
with...](http://www.igvita.com/2011/12/01/web-vpn-secure-proxies-with-spdy-
chrome/)

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_...](http://www.developer.nokia.com/Community/Wiki/Series_40_web_apps_-
_FAQ) (look under architecture)

Same story as Opera Mini.

~~~
mqzaidi
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.

~~~
igrigorik
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.

~~~
RyanZAG
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.

~~~
VMG
The point of SSL is that a TCP relay doesn't impact the security. Same is true
for for a proxy and HTTP CONNECT.

(The question remains if the Nokia browser does HTTP CONNECT)

------
noonespecial
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.

~~~
bad_user
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.

~~~
noonespecial
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.

------
fish2000
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.

------
chmike
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.

