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 funny thing is, Nokia's Xpress Browser did the opposite (for a day), allowing people in China to browse any site on the internet. It worked like a secure proxy or VPN, punching a hole through the Great Firewall. Until China caught on and blocked the IP addresses of Nokia servers.
If you read the linked Washington Times article, the "monitoring centers" sound like separatete bells-and-whistles products that are not the same as the mandated LI mechanisms.
Lots of other vendors market these government espionage tools to autocratic regimes too. Eg Bluecoat, Cisco etc.
At any rate it feels bad that we have to appeal to these human rights abusing autocracies, it's not any better to have these mechanisms built into the western networks.
If I use Thunderbird to send an email to foo@example.com, via Gmail, submitted with TLS encrypted SMTP on port 587, and Google decrypts my transmission and forwards it to mail.example.com unencrypted, is Google performing a MITM attack on my communication with example.com? No, they are providing the service I requested.
The Nokia browser is essentially a thin client that communicates with a remotely hosted web browser. The remote web browser, running on Nokia's servers, does all the complicated JavaScript and advanced CSS stuff, and converts it to a dumbed down version that can be displayed on the phone.
There clearly is a cost savings in using low-end parts. Not all screens are created equal, for example the Nokia Asha 306 uses a 240x400px resistive touchscreen. If you have ever used a phone with a resistive touchscreen you know how bad they are. It also has 32MB of RAM, 10MB of user storage, 2G data (not 3G), and no GPS. You can't run a WebKit + V8 browser on a phone with those specs, you just can't.
In your example the certificate you're being given when connecting through SMTP is for smtp.gmail.com.
It is this certificate that proves your connection is to smtp.gmail.com and not somebody else. That's the whole freaking point of HTTPS. What Google does from there, it's their business, but NO, they are not the man in the middle, as you explicitly and willfully connected to them and allowed them to send email on your behalf.
On the other hand, connecting to HTTPS with one of these Nokia phones leaves you with the impression that HTTPS connections to google.com are secure, when in fact the Nokia device is LYING TO YOU.
The example you've given couldn't have been any worst.
Nokia is not faking certs. The "browser" only talks to .browser.ovi.com and the SSL certs are issued to .browser.ovi.com. SSL is working exactly as they should. The "security researcher" didn't understand the results he was seeing and freaked out. The Nokia phone only does a DNS lookup of .browser.ovi.com, it only connects to .browser.ovi.com, and it only gets an SSL cert from .browser.ovi.com.
I don't think the issue is quite as black-and-white: does the physical location where a computation is performed really of any importance in this case?, You don't have control over what's going on in the hardware anyway. I'm not condoning Nokia, but I really don't see any difference here.
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.
except most people don't know what SSL is, and how it applies - other than that padlock. IN this case, the padlock doesn't prevent nokia from eavesdropping on you. But when asked, a non-technical customer wouldnt know or understand this, and thus opt in, where as if they did understand it they won't 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.
How is this in any way analogous to the Nokia situation? Nokia aren't passing traffic through their proxy because they want access to your data, they're doing it because your device isn't powerful enough to perform the necessary computations itself.
It's a privacy concern as it is. Please don't muddy the waters by spreading FUD and conflating this with something it's not.
Dealer wants to sell you a car, but installs an internal monitoring camera to do maintenance in order to see the condition of the roads you drive on. But doesn't tell you.
Lets say I run a mail forwarding service. I get your permission to go to each of your mail boxes and send your mail to where ever you happen to be. Mail is heavy though and to save you money I open all your mail remove a couple of pages / brochures / ads, reseal it in the original envelope and don't tell you.
I promise I don't read your mail when I get caught.
I'm giving the first 3 months free, please provide your information below so I can get started today!
> 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.
It's not a web browser in the way you are thinking of. It's a client for a Nokia service. The client does not attempt to connect to a website, instead it asks the Nokia service to render a website and provide a rendered version.
These phones are too under-powered to render modern web pages. It's either this or they have to view only WAP pages. If you have never used WAP on an old phone, go login to Yahoo Mail at http://wap.yahoo.com/
http://www.opera.com/mobile/specs/ Opera Mini in that picture is basically the same as the Nokia browser. You are not client, you just control remote client that will communicate with web server, retrieve data, process them and display them to you.
Overly complicated comparison would be you controlling browser on a remote desktop. Nothing has to be cracked, yet you can see data on your computer while the other computer can see them too.
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.
Nokia Xpress is available for Lumia[1]. Just like Apple doesn't allow alternate browser engines on iOS, but it allows Opera Mini[2] because Opera Mini isn't a full web browser, it's a client for Opera's transcoding service. Nokia Xpress isn't a full web browser, it doesn't execute JavaScript, it is a client to Nokia's transcoding service.
Yes, they allow alternative browsers. I've seen web browsers on the marketplace (SurfCube, for example) completely functional. What I'm not so sure is if they allow browsers using other rendering engines than Trident (i.e., they don't use the native WebBrowser control).
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.
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?
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.
Facebook and Gmail don't handle your connection to your bank.
Apart from that, we already know the Chinese have hacked GMail accounts on several occasions, so Google is already a definite target and the Incidents that have been reported may be just the tip of the iceberg so far as we know.
We also know that there have been cases of corporate and government espionage in the recent past. This is happening, right now, and we may never know how extensive it is. It's entirely possible that Nokia could become a target of either technical or even employee infiltration. If so, covert access to a service like this would be a fantastic coup, especially since Nokia phones are still popular in many parts of the world with unscrupulous and technicaly sophisticated governments.
Despite the irony, I'm not arguing it should be less of a concern.
Recent mishandling of user accounts by Sony Entertainment and LinkedIn gave us a glimpse of how much damage an intrusion can cause, even though (?) their management thought their intended purpose couldn't lead to any serious liability (speaking through my hat here).
Can a normal proxy server decrypt your HTTPS even it if wants to? I'm by no means an expect on cryptography, but I assume they're only able to do this because they can include their keys on Nokia devices and tell them to trust it.
When I access a proxy on my computer, it can't do that. If an arbitrary proxy could MITM a secure connection, HTTPS would be useless.
No, an ordinary proxy cannot do that. HTTPS is supposed to be end-to-end. I.e. the communications can only be decrypted by the two endpoints. One of the main reasons for signed SSL certificates is to prevent a middleman from masquerading as the endpoint and convincing your browser to negotiate encryption with the middleman rather than the real endpoint.
So I presume the Nokia browser is complicit in this scheme.
google chrome sends all my pages to translation and what-not. I have to completely trust it. that's why i never use the compiled version but the chromium one only (hence not having access to any addon via the addon site, have to do some manual work there)
Even besides the browser, how many computers don't I see the skype button next to phone numbers? would you trust skype is behaving and not sending your data to their servers? did you remember to disable this add-on for ssl pages?
A browser based on an open-source codebase with many people auditing its source-code and network traffic (there was much paranoia about Chrome when it was released). And even in that case, you have the choice to use a completely open-source browser that has a different stance on user privacy (Firefox).
An NPAPI plugin that can be easily disabled.
A third-party BOX MITM all your secure connections without your knowledge.
I don't think the above are comparable in magnitude.
You're right--the third is the worst by far. And this proves that you can't trust a pre-installed, commercial browser until it has been thoroughly audited by independent researchers.
They don't decrypt HTTPS. The NokiaBrowser (former OviBrowser) is a "proxy browser", a different application that talks to Nokia servers and these servers than establish a regular HTTPS connection. The same as Opera Mini. There is one more layer of abstraction.
Do you trust your phone operating system? How do you know it is not capturing your data when you access a bank website? Same issue here.
The one difference is that the Nokia servers might be a bigger target for hacking, instead of hacking individual phones.
If the proxy also gives you certs to trust it can. Many corporate proxies do this (silently, as they control the PCs) and I've seen more than one academic campus where to access the wifi you have to accept a certificate.
On iOS this comes up after connecting to wifi as a reassuring, secure-seeming, official-looking page that pops up inviting you to accept the new certificate. Do so and boom, you're vulnerable to a MITM.
Unless you control the CA certs installed in the browser, which nokia does, you can't generally decrypt https connections, which is the issue here. It's a man-in-the-middle attack but it's being used "for your own good".
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.
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.
Certainly they don't log "all that goes through" them; that would be stupid and not really practical. However, nothing is stopping them from logging all data from specific persons of interest, or using MITM attacks to discover passwords, etc. Law enforcement, spy agencies, and others would be very interested in such a capability.
The whole point of HTTPS and end-to-end crypto in general is that you know the communication is private between just you and your counterparty. If you subvert HTTPS so that there are middle men, that is broken.
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.
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.
The lower end Asha 30X series has 32MB of RAM and 10MB of internal storage to play with. Squeezing a real browser with acceptable performance into that is probably non-trivial.
The second aspect is one of bandwidth. Pre-processed sites are a lot smaller than the full sites. Many people with these phones probably don't have data contracts with generous limits. And when you're paying pr byte and downloading over GPRS, every byte that doesn't have to be downloaded counts.
Your calculation forgot to include a decade of web evolution. Surely you agree that webpages from 2002 are different to those from 2012. Whether it's the size (images, javascript, html, css), complexity (css, html, javascript) or functionality (css, html, javascript).
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".
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.
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.
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).
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.
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.
Yes, but Opera basically say that there are using a MITM approach:
> 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.
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.
Maybe that might be so, but I still had Nokia until 2 weeks ago and still won't have either Android or iPhone. Thing is basically until now I have only used Nokia phones and that might be somewhat understandable when I say I'm Finnish.. Anyway security should never be exchanged for speed.
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.
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)?
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).
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.
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?
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.
It's more like a browser running on a remote desktop (you have hopefully exclusive access to) which sends your phone the repackaged html and recompressed images instead of a screencast.
My guess is that the browser just won't tell you who the other party is. Whenever you go to a secure site you actually connect to (and are encrypted with) Nokia's server. That server then connects to the remote site securely.
The only way I can think is if Nokia operate their own CA and configure the phones to trust it. They then issue their own certificate for any site you visit which your phone will trust.
I don't think that's what is happening, we need further explanation. Although if that is what is happening it;s really bad as they would effectively be impersonating the sites.
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.
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?
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.
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.
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.
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.