

Nokia: Yes, we decrypt your HTTPS data, but don’t worry about it - rmk2
http://gigaom.com/2013/01/10/nokia-yes-we-decrypt-your-https-data-but-dont-worry-about-it/

======
antoncohen
The Nokia Xpress Browser is not an HTTP web browser. It is a specialized
client that talks to transcoding servers. It is designed for low-end phones in
emerging markets. These phones have 128MB of RAM or less, they are not capable
of running full web browsers. If a user has a phone capable of running a full
browser (like the Lumia phones) and they choose to install the Nokia browser
or Opera Mini to save on data usage, they are opting-in for the service. The
compressing browser is not the default browser for Nokia phone running Windows
Phone 7/8, MeeGo, Symbian^3, or S60.
[http://www.developer.nokia.com/Community/Wiki/User-
Agent_hea...](http://www.developer.nokia.com/Community/Wiki/User-
Agent_headers_for_Nokia_devices)

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.

~~~
leoh
I'm sort of confused as how this works. If it is not a MITM attack (i.e. using
false SSL certificates), then how is Nokia readily decrypting data? I thought
SSL was relatively non-trivial to crack.

~~~
crdoconnor
Your phone is basically just remotely using a browser on Nokia's servers.
Their servers are the ones actually initiating the SSL connection.

~~~
leoh
Got it. I think the title of the article is misleading when it says they
decrypt the data. It's true of course, since they hold the client certificate.
I hope data is ferried to their server in an encrypted format at least.

------
zmmmmm
Surely this is a giant target painted on Nokia's proxy servers for any
blackhat out there who wants to intercept a whole lot of https traffic? Seems
like a horrible security incident just waiting to happen.

~~~
tveita
Sounds like a lot of work just to listen to random web traffic. Why not break
into Facebook or Gmail instead? Then you could spy on anyone you wanted.

~~~
zmmmmm
Why go to the work of breaking into Facebook or Gmail when you an just exploit
this proxy and get Facebook accounts _and_ Gmail accounts _and_ bank web sites
and a million other sensitive things too?

~~~
malandrew
Because I would bet that the security professionals working for and contracted
by Google and Facebook to be an order of magnitude better at their jobs than
those hired by Nokia. I would expect Google and Facebook to be better at
closing holes and better at detecting and closing security breaches if and
when they do happen.

~~~
randomtask
You know you just agreed with the comment you replied to right?

~~~
malandrew
Oops... I was distracted while reading and didn't read carefully enough.

------
modeless
Now that this is known, how long until Nokia starts receiving government
requests for HTTPS interception? I'm guessing less than a year. Of course,
we'll never actually know.

~~~
tobylane
There's a difference between being the middle man so you can minify for the
user, and logging all that goes through you. Just because we can't detect that
change anyone who offers that service is a government lackey?

I like Opera Mini, which is just like this. But I hope my bank blocks it.

~~~
yk
Of course there is a difference between just Mitm for compression and outright
eavesdropping. But with this point of attack a government can simply walk to
Nokia with a court order, and Nokia will comply, most likely without much of a
fight.

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.

~~~
darkarmani
> But with this point of attack a government can simply walk to Nokia with a
> court order, and Nokia will comply, most likely without much of a fight.

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.

------
anuraj
The Nokia Express browser and Opera Mini are built this way and technical
folks know this. These browsers are used in resource constrained devices that
cannot run a full fledged web browser and also conserve on bandwidth which is
crucial for countries like India where 3G coverage is still patchy and
expensive. I think user has the right to be better informed in this case. So
is the case with Google Chrome which relays each and everything you do back to
Google servers.

~~~
justincormack
Funny there is an article today about how Safari had to run in 128MB RAM when
it came out, which is apparently what these phones have. So writing a real
browser may well still be possible.

~~~
anuraj
A phone's 128MB memory is not same as PC's 128MB. Phones usually have execute
in place (XIP) memories, which means the OS and apps share some space. Also
each app is budgeted a certain memory (Phones use near real time OSs compared
to usual OSs in PCs), so as not to exceed the memory limit anytime. There is
no virtual memory to grow to. So the assumption is not correct especially for
feature phones that do not use modern smart phone OSs which are more nearer
(by no means same) to desktop counterparts.

------
benatkin
I'd love for Google to block all HTTPS traffic coming from Nokia's server,
citing security concerns. That would make Nokia change their tune real quick.

~~~
gcb0
it's not insecure if you trust the company.

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.

~~~
esrauch
I don't see how everypass.com is relevant.

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.

------
pyre
Bad analogy time: It's like you're SSH'ing into a remote machine, then using
w3m to access <https://google.com>. Then you complain that your outgoing local
connections are to the server instead of to google.com.

~~~
rplnt
It's actually a perfect analogy.

------
drcube
Why is this necessary? Shouldn't all encrypted traffic be compressed to begin
with?

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?

~~~
A1kmm
> Why is this necessary? Shouldn't all encrypted traffic be > compressed to
> begin with?

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.

~~~
mcherm
Excellent explanation, thank you!

------
welder
The guy who originally discovered this:

<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...](https://www.pcisecuritystandards.org/documents/Prioritized_Approach_V2.0.pdf)

~~~
Coincoin
Even if they had to, they would be. Everything transmitted over a public
network is encrypted.

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

~~~
Firehed
Merely touching plaintext data at some point is enough to get scoped into PCI
requirements, even if only in memory.

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.

------
Permit
Why is it that Nokia gets ripped apart for this, but Opera-mini gets a free
pass? This is not the default behavior for Internet Explorer, you'd have to
opt-in.

~~~
rplnt
It's about page views. There's nothing revolutionary or wrong with this. It's
specific browser for specific purpose. It's a documented behavior. It's been
used for years. Nothing interesting about it.. unless you write and article
like this to bait the readers and make them share it.

Another option is the author is an incompetent idiot (news-writing-wise).

------
MichaelGG
This will be true for any "server accelerated" browser that needs the server
to render or modify content, like Opera Mini.

How could they compress/optimize the pages coming to you, if they can't read
it?

~~~
Zirro
They could exclude HTTPS-pages, or at least include an option to do so.

~~~
anonymfus
In case of Opera Mini client part of browser does not have technical ability
to parse and render html.

~~~
micampe
Does it have the ability to access HTTPS content?

~~~
rprasad
Yes. If you read the terms of service for the Opera Mini browser, they
disclose that HTTPS sessions are not end-to-end.

~~~
kalleboo
It also requires you to OK through a warning the first time you access an
HTTPS site, so it's not a fact that's buried in some legalese.

------
hn-miw-i
<http://gaurangkp.wordpress.com> has this completely wrong. I wished he had
published my comment on his blog (I was first post).

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.

------
mixedbit
They do it for caching purposes? What if some destination HTTPS servers return
incorrect caching headers for sensitive data, because, hey, the content is
encrypted so public caches have no way to store it. But now, Nokia caches can
potentially store such sensitive content and leak it.

~~~
Coincoin
It's so they can compress the data and save on your data plan. You can't
compress encrypted stuff, so they temporarily decrypt it, compress then
reencrypt.

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.

------
alan_cx
People should stop thinking "geek". A mug punter is going to be freaked out
that the advice that HTTPS means their data is secure will not care to
understand technical BS that excuses the fact that HTTPS is not secure in this
instance.

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

~~~
pyre
The options are:

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
    

Nothing is every truly, 100% secure. People like black-and-white answers.
People either want "it's secure" or "it's not secure." People can't normally
handle, "it's secure-enough for these use-cases, but not for these other use-
cases." A normal browser could easily trust a fake-certificate that was issued
incorrectly by a trusted source. I'm unsure how you fit these sorts of things
into your world-view, but it would behove you to do so.

    
    
      | its not what it says on the tin.
    

If you can find a tin that says so, you should attempt a false-advertisement
claim.

------
hn-miw-i
Nokia is not intercepting your https! They are doing nothing dodgy here.

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.

------
logn
This is a similar vulnerability to WAP. Nokia is providing a service: people
with slow connections and cheap phones want it or need it.

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.

------
viveksec
I work in deep packet analytics and have interacted with several telcos and
vendors. If you are developing a packet analytics or metrics product the
temptation to tap into your production traffic, if only for validating your
product is too strong. In our segment, access to live traffic is the primary
"raw material" to develop, test, and enhance the products. So they may not use
your data to "spy" but there is no protection against your data making it into
packet captures (tcpdumps or pcaps) which then acquire a life of their own. I
am not saying Nokia does this, but that any telco/vendor including this one
who makes packet analysis products has to fight the temptation not to do it.

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

------
aleprok
I will never again buy a Nokia phone.

~~~
hbharadwaj
You do realize Nokia Lumia phones have IE as well as Xpress? This issue
affects Xpress alone. You could use IE without any of this affecting you.

~~~
dscrd
The Lumias have this Xpress thing?! Why?

~~~
hbharadwaj
Essentially, Nokia improves webpage load performances by utilizing data
compression algos on their servers through Xpress - similar to Opera and
Amazon Silk. In between, Nokia decrypts HTTPS traffic - Opera and Amazon
apparently don't.

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.

------
daftdoki
Even if Nokia isn't looking at your information, they're breaking the trust
model of SSL even more than it already is. Since they would have to terminate
SSL at their proxy server, you lose control of what certificate authorities
you trust, and what certificates you trust. Not having one of these phones, I
can't speak to the specifics, but it takes a lot of the ability for the user
to verify the authenticity of the https connection.

------
hn-miw-i
Nokia pushed out an update that uses an http proxy for Phone to server TlS.
The worst thing about this is that they have diluted their security model (tls
in tls is resistant to single interception-- ie tor).

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.

------
plasma
How is this possible? Is there a built-in certificate on Nokia phones that
accept the proxy server certificate (which must be a wildcard for everything)?

~~~
marcosdumay
> Is there a built-in certificate on Nokia phones that accept the proxy server
> certificate (which must be a wildcard for everything)?

Excatly.

------
sparkinson
I understand that there is an expectation for Nokia to resolve this concern in
some manner, but why do endpoint sites not simply block requests from the
proxy?

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

~~~
slavak
What makes this proxy less secure than any other HTTPS proxy?

------
Tichy
How do they decrypt HTTPS? That shouldn't be possible? Are they exchanging
certificates in the middle?

~~~
mcherm
They sold the phone, and so they controlled the browser installed on the
phone. HTTPS is only secure if you can trust both ends: the receiving end and
your browser. In this case, the browser was unreliable.

~~~
Permit
This is not the default browser installed on the phone.

~~~
fulafel
Yes it is, see for example the bit about the browser at
[http://www.nokia.com/global/products/phone/asha205/specifica...](http://www.nokia.com/global/products/phone/asha205/specifications/)

------
idlecool
Is it even possible? HTTPS is used to avoid any possibility of man in the
middle attack. How can nokia's proxy servers be able to decrypt that encrypted
information unless they themselves have the private key?

~~~
elemeno
It's pretty standard for corporate proxy servers - at least in financial
companies where theres regulations that tend to require some level of
monitoring of external communications.

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.

~~~
richardwhiuk
Actually corporate proxy servers generally use CONNECT to allow HTTPS through.

~~~
idlecool
and what is that?

~~~
carey
Wikipedia describes it briefly at
[http://en.wikipedia.org/wiki/HTTP_tunnel#HTTP_CONNECT_Tunnel...](http://en.wikipedia.org/wiki/HTTP_tunnel#HTTP_CONNECT_Tunneling).
The most recent standard for it appears to be RFC 2817 section 5.2,
<http://tools.ietf.org/html/rfc2817#section-5.2>, and it’s also in the HTTPbis
Semantics and Content drafts, currently at [http://tools.ietf.org/html/draft-
ietf-httpbis-p2-semantics-2...](http://tools.ietf.org/html/draft-ietf-
httpbis-p2-semantics-21#section-5.3.6).

~~~
idlecool
thats super cool.

------
cosmikduster
Now that we know Nokia is doing this, why shouldn't Banks, Facebook and Google
reject any traffic coming from Nokia's proxy servers?

------
Udo
When Amazon did the exact same thing (offering a browser that had its endpoint
on an external server) everybody was euphoric because it allowed a modern
rendering engine to "run" on a very limited device. Now Nokia does the same
thing for crippled phones and they're the bad guy.

~~~
jargonjustin
No, Amazon Silk routes HTTPS traffic directly to the origin server.

[https://www.eff.org/2011/october/amazon-
fire%E2%80%99s-new-b...](https://www.eff.org/2011/october/amazon-
fire%E2%80%99s-new-browser-puts-spotlight-privacy-trade-offs)

------
jacquesm
Nokia just killed their brand.

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.

~~~
hosay123
How is this any more insidious than already trusting the company to remotely
update code on the device? Or (in the case of Google) on your desktop.

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?

~~~
jacquesm
When a device I own tells me I'm talking to my bank directly, but instead I'm
talking to the producer of the device that's a man-in-the-middle-attack in
progress.

After that said producer of my device is definitely in my 'to be avoided'
category.

------
dakimov
Actually, I want to say: what the fuck?! Nokia are you that stupid? This is no
joke. I used to think that when I use HTTPS my data are encrypted right in the
browser, and I send some really sensitive data via HTTPS connections. "We're
just compressing stuff... It's ok..." Really? I mean, really? Are you that
lame? I don't use anything Nokia's anyway, but I hope other companies are not
that stupid.

~~~
dakimov
Why is the comment greyed out only because some stupid jerks are not agree?
What the hell? What if 99% of the clever people are agree? But clever people
are still 5% of the human mass. This is a wrong ranking system, this is a
dictatorship of the stupid. I am going to think of this as of the 'rejection
therapy'. I am not going to conform the public's opinion anyway, just don't
give a rat's ass.

------
dakimov
In a better world, this would be against the law.

