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...
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.
The expectation of using an SSL connection is that there will be end to end encryption. This is not the case here, and the user should be informed and given the chance to opt-in.
An interesting question, if Nokia informed their customers before the purchase would they have still bought the hardware? It's not really quite as altruistic of Nokia they don't put the cards firmly on the table before hand.
> If you don't trust Nokia, don't use their phones
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).
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.
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.
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.
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.
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 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.
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.
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.
That's great for security, but not for freedom. The problem is that people just assume they're secure, and they should be aware that if they're going to use these browsers, they're trusting Nokia with their information in exchange for a faster and more compact data transfer. But having Google refuse service because you choose to trust Nokia is silly. A warning shown to users would be a more palatable solution, in my opinion.
Of course, when Google breaks them they'll write a fully-fledged browser for those phones that works as smoothly as the thin-client one. Because they merely chose to do that not because the former is impossible, but because they wanted to be evil. They'll just "change their tune".
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.
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?
> 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.
They like to crush images. I'm on a mobile dongle (T Mobile, UK) and I'll happily take some screenshots if anyone has some test gifs anywhere. Mine don't interfere with SSL. But a lot of other stuff is weird or broken.
It's not just compression. These kinds of schemes can e.g. eliminate a massive number of extra roundtrips over a high latency mobile link. Or eliminate most uplink traffic completely (basically you'd just need to issue a request for the main page, all the subresources could automatically fetched by the proxy server and pushed to the client without it specifically requesting them). And that can be a huge win on mobile, since uplink tends to be way slower than downlink and often becomes a bottleneck for pages with many small resources.
No, this is more like a thin client for devices that are too weak to actually run a browser. The device doesn't even render anything, it just receives pre-rendered pages from the server.
Should be obvious that it has to decrypt HTTPS to work with it at all.
I'm not sure about Nokia's service specifically, but in general these kinds of services do more than just zipping files. Some things they do:
* resize images large images to match the screen resolution
* limit the number of HTTP requests the phone itself is making
The point of most encryption algorithms isn't to compress the data or remove redundancy, at all. In fact, most widely used algorithms are block ciphers that don't change the size of the data.
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.
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.
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.
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.
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.
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.
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.
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.
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).
Wow Jesus Christ. This isn't the default on Nokia phones. You'd have to specifically NOT use the default browser and download the Nokia browser to be exposed to this.
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.
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.
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)?
[+] [-] antoncohen|13 years ago|reply
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.
[+] [-] zurn|13 years ago|reply
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.
[+] [-] benatkin|13 years ago|reply
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?
[+] [-] nodata|13 years ago|reply
[+] [-] Nikker|13 years ago|reply
[+] [-] tripzilch|13 years ago|reply
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...
[+] [-] leoh|13 years ago|reply
[+] [-] zmmmmm|13 years ago|reply
[+] [-] tveita|13 years ago|reply
[+] [-] elemeno|13 years ago|reply
[+] [-] modeless|13 years ago|reply
[+] [-] pdonis|13 years ago|reply
[+] [-] tobylane|13 years ago|reply
I like Opera Mini, which is just like this. But I hope my bank blocks it.
[+] [-] rplnt|13 years ago|reply
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.
[+] [-] zurn|13 years ago|reply
[+] [-] M0nkey|13 years ago|reply
[+] [-] anuraj|13 years ago|reply
[+] [-] justincormack|13 years ago|reply
[+] [-] benatkin|13 years ago|reply
[+] [-] TallGuyShort|13 years ago|reply
[+] [-] nathan7|13 years ago|reply
[+] [-] gcb0|13 years ago|reply
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.
[+] [-] pyre|13 years ago|reply
[+] [-] drcube|13 years ago|reply
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|13 years ago|reply
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.
[+] [-] DanBC|13 years ago|reply
[+] [-] jsnell|13 years ago|reply
[+] [-] brazzy|13 years ago|reply
Should be obvious that it has to decrypt HTTPS to work with it at all.
[+] [-] wikyd|13 years ago|reply
[+] [-] tachim|13 years ago|reply
[+] [-] welder|13 years ago|reply
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...
[+] [-] Permit|13 years ago|reply
[+] [-] MichaelGG|13 years ago|reply
How could they compress/optimize the pages coming to you, if they can't read it?
[+] [-] hn-miw-i|13 years ago|reply
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|13 years ago|reply
[+] [-] Coincoin|13 years ago|reply
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.
[+] [-] obituary_latte|13 years ago|reply
>...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.
[+] [-] alan_cx|13 years ago|reply
"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|13 years ago|reply
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.
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. If you can find a tin that says so, you should attempt a false-advertisement claim.[+] [-] hn-miw-i|13 years ago|reply
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|13 years ago|reply
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|13 years ago|reply
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|13 years ago|reply
[+] [-] Permit|13 years ago|reply
[+] [-] btilly|13 years ago|reply
[+] [-] hbharadwaj|13 years ago|reply
[+] [-] daftdoki|13 years ago|reply
[+] [-] hn-miw-i|13 years ago|reply
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|13 years ago|reply
[+] [-] marcosdumay|13 years ago|reply
Excatly.