The statements I have posted on this site are mine alone and do not necessarily reflect the views of Unisys
Tested On
| Handset Model | Nokia Asha 302 |
| OS Version | 14.78 (31-08-12), RM-813 |
| Browsers Tested On | Nokia Browser (2.2.0.0.31) |
| OS Type | Series 40 (S40) |
After discovering that HTTP traffic from the phone is getting redirected through Nokia’s server farm as shown in previous post, the most obvious next step was to check if at least HTTPS traffic is getting its due respect and is being transferred without any intermediate host inspecting it. Due to fact that HTTPS traffic is encrypted before getting transmitted, it is not possible to look at HTTP(S) packet header in order to figure out details as was done in case of HTTP as per previous post. However there are two ways to get an idea of how traffic is flowing.
- Check if DNS requests are sent for requested website.
- Check certificate sent from server
DNS Request Check
The goal of this test was to find whether the phone is sending DNS query for site that is being requested to be browsed. To test this we had browsed site https://www.google.com through Nokia browser. Ideally the phone should have send DNS query requesting IP address for “www.google.com”, which would have looked normal. On the contrary when checked, the DNS request was sent for “cloud13.browser.ovi.com” which is same host where we had seen even HTTP traffic being sent as per previous post. Not just that, there was no attempt made to resolve “www.google.com”. The wireshark snapshot given below proves this fact, but there is no way from wireshark snapshot taken off wifi router it can be proved that the request was originally made for https://www.google.com and not for cloud13.browser.ovi.com.
Certificate Response Check
It is evident from above snapshot, that even https requests are also getting redirected to Nokia/Ovi servers, which raises a question about certificate that it being received from Nokia’s servers and trusted list of certificates in Nokia phone in subject. Let us first look at certificates being received from Nokia servers during this transaction. Given below is packet sniff from wifi router.
When checked trusted certificates in phone it is found that Nokia has pre-configured the phone by trusting at least one of these certificates, which is the reason why there are no security alerts being shown during this Man In The Middle (MITM) attack by Nokia. The snapshot given below shows details about each of the three certificates that are shown in packet capture.
One more thing that should be noticed here is that the DNS request was send for “cloud13.browser.ovi.com” where as certificate (middle one) says it was issued to “cloud1.browser.ovi.com”, and still there was no security warning thrown on the phone.
Conclusion
From the tests that were preformed, it is evident that Nokia is performing Man In The Middle Attack for sensitive HTTPS traffic originated from their phone and hence they do have access to clear text information which could include user credentials to various sites such as social networking, banking, credit card information or anything that is sensitive in nature. In short, be it HTTP or HTTPS site when browsed through the phone in subject, Nokia has complete information unencrypted (in clear text format) available to them for them to use or abuse. Up on checking privacy statement in Nokia’s website following can be found.
Websites accessed The URLs of such sites which you access with the Nokia Browser are stored by Nokia. However, we will not collect any personally identifiable information in the context of providing the service. Your browsing is not associated to any personally identifiable information and we do not collect any usernames or passwords or any related information on your purchase transactions, such as your credit card number during your browsing sessions. Also, additional parameters in the URL are not stored.
For additional information on their privacy policy you may want to visit their Privacy Policy Page or Nokia Browser Privacy Policy Page
Update of 10th January,2013
Just noticed when I tried to browse a site through Nokia browser, I got a message to upgrade browser. I clicked remind later as I wanted to something. My guess is Nokia would have fixed this. But nothing can be said without actually upgrading and testing. Also seeing “Update your browser” in browser.nokia.com. Since no date/time stamp is given there it can not be confirmed if this is new or old.
Update of 11th January,2013
Just upgraded my Nokia browser, the version now is 2.3.0.0.48, and as expected there is a change in HTTPS behaviour. There is a good news and a bad news. The good news is with this browser, they are no more doing Man-In-The-Middle attack on HTTPS traffic, which was originally the issue, and the bad news is the traffic is still flowing through their servers. This time they are tunneling HTTPS traffic over HTTP connection to their server. Details are given below.
This time again we had browsed https://www.google.com, and found that again DNS requests are sent for Nokia/Ovi servers and this time it was “cloud13.xpress.nokia.com”. Up on receiving DNS reply, a HTTP tunnel is eshtablished between Mobile device and their cloud server and HTTPS traffic is tunneled over that HTTP tunnel.
The snapshot given below shows DNS query and HTTP traffic for HTTPS site.
Also HTTP header shown below confirms this info where “x-nokiabrowser-host” parameter informs Nokia server to fetch a perticular HTTPS url and later the content is passed over to mobile device. We are yet to try seeing certificate information in this as it is neither available from Phone nor from packet sniff as was possible previously. I am yet to check how is GET/POST requests to a HTTPS site is handled.
POST / HTTP/1.1 Host: cloud13.xpress.nokia.com Content-Type: application/octet-stream x-nokiabrowser-host: https://www.google.com connection: Keep-Alive accept: */* cache-control: no-cache x-device-id: <removed> Content-Length: 362 Connection: Keep-Alive User-Agent: Nokia302/5.0 (14.78) Profile/MIDP-2.1 Configuration/CLDC-1.1 x-wap-profile: "http://nds1.nds.nokia.com/uaprof/Nokia302r100.xml" ETLV.4J....I...G..L....[OUTPUT-CUT]
I would like to Thank Nokia officials for quickly responding to the issue and getting it fixed on priority. This shows their commitment towards privacy of their mobile customers, much appriciated.
Fresh commenting/pingbacks has been disabled on this post.
Treasure Hunt 
Pingback: Nokia – a scary behaviour | /home/kOoLiNuS
excellent post Gaurang . Moral dont use Nokia/any other phone for money transactions 🙂
Should Appreciate Gaurang’s work
This is a hotly contested topic (browsing proxies). “Yet Another Certificate MitM”, http://lists.randombit.net/pipermail/cryptography/2013-January/003686.html. Some folks (like myself) don’t want the secure channel tampered. Others accept it as business as usual.
I believe many phones redirect traffic through an internal proxy server that provides reformatting for the mobile device. That being said, I’m not thrilled with the impact of this. That’s the main reason I still don’t do any banking from my phone – even through the bank-approved and provided app.
Well, actually the tests do not in any way support the conclusion that Nokia is breaking up the SSL connection between the destination server and the handset. All it shows is that the handset is using an SSL connection to a proxy server of some sort (and not resolving the destination hostname on its own is expected behaviour in that case). It might as well issue a CONNECT to the destination server and then set up SSL inside – or establish the end-to-end SSL in a different way.
It definitely does break SSL connection, as I am seeing google page from Nokia’s server which is evident from cert, which is of Nokia’s.
Pingback: DD Tech Solutions - Nokia seems to be hijacking traffic on some of its phones, grabbing your HTTPS data unencrypted
This doesn’t show a man in the middle attack. You need to show you received a certificate was recieved that appears to be from google but is not, and you need to show that that certificate is trusted by the installed root certificates.
Not necessarily, pls check https://www.owasp.org/index.php/Man-in-the-middle_attack for details.
Gaurang,
I’m sorry to be blunt but the only thing this article is showing me is you do not understand how PKI and crypto work in general.
The _only_ thing you need to show to prove a SSL/TLS connection is MITM and the certificate is forged is to show _two_ certificates for the _same_ name with different fingerprint. In your entire article you not only never mention that word but you even fail to show the correct page on the windows certificate box.
If you want to be more convincing you can also show the “invalid’ root or intermediate that is being used to build the chain of trust for the “invalid” cert.
The wireshark captures you are showing are not a proof of _any_ sort since all they show is that the OVI app is talking to their cloud – most likely update applications catalog or something else.
Unfortunately I do not have a single URL to provide since there is a lot you need to read to be able to understand what is happening but I would say read one the openssl utility and the options it has for exploring certificates and also read on PKI and how the trust is established.
Also you may read on how proxying SSL connections work. It’s perfectly Ok to proxy those without decrypting them.
As to Nokia’s answer you may want to read carefully. Notice they are not even admitting to doing so. It is gently implied but they do not even confirm you have a case 🙂 This is just because your research is so far off it’s not even worth addressing it (from their point of view).
Mate, next time try peer-review before publishing.
Cheers,
Thank you for your blunt reply… 🙂
John Lane your comment is not blunt but sick, your statements do not prove anything expect they are targeted to humiliate Pandya.
Do you work for Nokia? or were hired for damage control.
Hello sathya,
No I do not work for Nokia and never have (or plan to).
The problem is that the blog post is displaying high level if illiteracy. This in a way is OK, everybody can make a mistake.
What bothers me is your friend keeps on arguing even after he was told by multiple people how wrong he is, instead of just reading on the topic.
I’m sorry you call this sick. You may need to do a little more research before you judge.
Cheers,
It’s that slippery slope issue. Yes, we collect your data, only to format it, making our phones look faster … but a little extra peeking will give us an idea how much money you spend, so maybe we can figure out how to get it?
Maybe we’ll post a good word or two about our phone on your facebook page? Maybe we’ll ‘feature’ other products too.
Nokia Executives. The best way to keep yourself out of trouble is to not go looking for it. Remember the Gold Rule? ‘Do on to others, as you would have them do on to you.’
Would you really like an unknown entity reading your mail? Opening your bank account or using your name as bogus product adverts?
This is no different then Opera Mini browser as it is stated that it goes through their proxy to compress data and stuff. Same with older model blackberry where it goes through the RIM Relay. Important thing is to ensure that the data is secure against non-authorized employees.
Pls check other comments and replies.
Opera Mini only relays the packets from HTTPS protocol connections which is a completely legimate action, it’s not the same thing as what Nokia are doing at all. Nokia is actively impersonating both you and your visiting HTTPS site in a Man in the Middle Attack style.
Are you beyond retarded? This is a FEATURE of Opera Mini, and no doubt the Nokia browser employs the same technology.
Data is compressed before being received by the phone that then decompresses and displays the page.
What an “Expert”.
No, opera states all these very clearly in their FAQ and other section unlike Nokia. Opera says if you dont like this behaviour use Opera Mobile, instead of Opera Mini Mobile, where is there is no such statements from Nokia.
I’m not sure this is a MITM attack. Looks like the proxy is using ssl to me.
In order for this to be a MITM attack the cert served to the device must be generated to have the correct common name of the site you are connecting to. Since you can’t generate certs signed by a valid CA, the generated cert needs to be signed by your own CA which needs to be trusted by the device.
Wireshark wouldn’t show you any of this, because that ssl negotiation is done inside of the SSL session built to the proxy.
The only way to tell would be to look at the certificate for the website on the device and confirm that the CA is a trusted CA, not one that Nokia slapped together.
Please show proof that this is the case before raising the red flag.
That one is also MITM, so is this. Its like this, user is browsing https://google.com, and is getting google.com’s page with secure connection. But when you verify the cert is of Nokia’s which means traffic is originally from Nokia’s server and not Google’s server which is what user expects as its HTTPS connection. Hence Nokia’s server is transparently coming in between user and end server which makes this MITM. Thanks.
You have accused Nokia of a grand crime and presented no evidence.
Show us where our browser thinks the google etc cert is from Nokia and not google.
Wireshark doesn’t mean squat. You saw the proxy https traffic…
Where do people get the idea that certs are the defining property of an MITM attack? Gaurange is quite right in calling this an MITM. Anything that involves an attacker using a proxy between two points to intercept traffic is technically an MITM attack, hence the name. MITM attacks can even be done within a local network, if the right MAC address is impersonated. The certificates themselves are incidental.
Does this apply to Series 60 (S60) phones such as the Nokia N8 (the s60 flagship) as well ?
or is this only for non smartphones (s40 featurephones) ?
Not sure, I had checked an old S60 phone C5-03 but did not see this behaviour, but this phone is newer, hence not sure if newer S60/80 phones have it.
I have an N8 with the latest firmware (111.040.1511) and Nokia Browser (8.3). I can confirm that, every time I accessed a “What’s my IP” website (both with and without HTTPS, with both GPRS and Wi-Fi) since I purchased the device (which came preloaded with firmware 13.016), I always saw my IP address.
But is that actually your mobile’s public ip address or some other is the question.
WHat is the APN definition on the phone?
Not sure if I got your question, but the phone picks up wifi if its available, else will fall back on 2g/3g networks. This one was tested on my home wifi.
thank you for this!
i wanted to clarify for future readers, that this is a separate claim from the nokia/opera article…This is only proving that Nokia, -NOT OPERA- is intercepting HTTPS traffic. Opera has a privacy policy that clearly states they do not boost https traffic, only normal http traffic. Nokia has no such policy or disclosure.
The two articles appeared together on slashdot today, and many inferred that the claim about opera in the other post also applied to the MITM with nokia. Despite being slashdot, it seems many do not read the articles they comment on….It is well know Opera boosts traffic. It was not known that Nokia intercepts traffic. That is a HUGE breach of trust. A single compromised certificate or proxy server…..well you can guess
The SSL certificate for cloud1.browser.ovi.com also has subject alternate names valid for cloud2.browser.ovi.com through to cloud13.browser.ovi.com so it is normal for there to be no security warning, because the certificate is valid for that site – your conclusion is wrong.
My statement about hostname in certificate name was just an additional comment, it does not change the fact that we are getting Nokia’s cert when browsing https site of google which should never be the case in normal browsing conditions. Any way thanks for that find about alternate names.
Most cell carriers do this. Some will warn you. Many do not. They load CA certs on the phone and some phones also by-pass proxy settings. iPhone is the most disturbing, as it pertains to the data collected.
we have seen carriers do it for HTTP traffic, also for HTTPS they might not actually intercept traffic. Here if you see cert that is received when browsing google.com is of Nokia’s which clearly means page that you are seeing though looks like google.com’s page is being presented to you from Nokia’s servers. This is what is problem.
Is it possible they’re using this proxy for web caching?
The issue is that the messages are optimized through a proxy. It’s very helpful in Thirdworld and other areas that don’t have flat rate packages. Opera Mini does that same thing. I still don’t like it.
Wow, you’re so smart…
Maybe you should read the manual for Opera? You would know then that this is a publicly disclosed feature, one that they advertise! Cheeezzz!
Pls check other replies and comments..for answer to this, this has not been most frequently posted comment. Will ignore other comments on the same line.
This has now made into news check this out.
We take the privacy and security of our consumers and their data very seriously. The compression that occurs within the Nokia Xpress Browser means that users can get faster web browsing and more value out of their data plans. Importantly, the proxy servers do not store the content of web pages visited by our users or any information they enter into them. When temporary decryption of HTTPS connections is required on our proxy servers, to transform and deliver users’ content, it is done in a secure manner.
Nokia has implemented appropriate organizational and technical measures to prevent access to private information. Claims that we would access complete unencrypted information are inaccurate.
We aim to be completely transparent on privacy practices. As part of our policy of continuous improvement we will review the information provided in the mobile client in case this can be improved.
You can find out more about Nokia’s privacy practices at http://www.nokia.com/privacy.
Mark Durrant
Communications, Nokia
Thanks you Mr. Durrant for giving this information, this indeed helps loyal nokia customers like me. Also it would be good if you can publish technical know-hows about what is happening behind the scene in order to protect customers privacy, as done by Opera guys for their Opera Mini browser, it would help.
Decrypting HTTPS traffic and using the Man-In-The-Middle-Attack as a company policy is a very bad idea. Even if Nokia is NOT reading the clear text data, it can only bring bad publicity. There is a reason why some people are using HTTPS, even if it is slower. Nobody should sacrifice privacy for speed. Also if your CA private key is cracked/leaked ALL your phones (millions?) HTTPS sessions are insecure.
Gaurang, can your commentators read?
This is nothing to do with proxying to optimise/compress images etc., but to do with https interception which should NEVER happen – The fact that Nokia install fake certificates on the phone to allow them to do this without an invalid certificate alert popping up is sneaky at best, and pretty dodgy.
Even if they don’t actually look at the data, they ARE performing a MITM attack which could be exploited if anyone hacked into nokias servers.
I’m guessing the ‘fix’ is to remove the dodgy certificates from the phone, but then I presume you’d never get https connections to work unless you accepted the incorrect cert..
Certainly we can read :), any way a communication from Nokia helps. But this doesn’t change the fact as you said that MITM is MITM and is certainly not good.
Thanks for the reply 🙂 I wrote my reply before I saw Nokias official response, my cheeky comment was aimed at those who kept bashing you by saying this is a “known feature for compressing web pages etc.”, whilst your article is about the https MITM issue.
I don’t mistrust Nokia under any circumstances, but there could always be a rogue employee who gets tempted.
Also, every dodgy hacker out there right now will be looking to crack the Nokia servers!
Where’s the fake certificate? The Nokia browser opens a proxy ssl connection to cloud{1..13}.browser.ovi.com for which it receives a valid vertificate. The proxy opens the connection to the final destination, which is responsible for encryption between itself and the endpoint. Results are sent using the previously validated certificate to the phone.
It’s only MITM in the way that any proxy performs MITM.
If you *must* have guaranteed end-to-end encryption you’ll need a different device, with a different browser.
Oh I see… So the browser itself is connecting (*not* proxying by the ‘proxy’ definition) to the ovi.com servers and relaying the request onwards.. In other words, it’s a browser MITM attack, not a proxy one (which would require a fake certificate to work silently).
This is still MITM, and *NOT* how transparent or any other proxies deal with https requests. All proxies basically simply create a tunnel for https connections, and don’t tamper with the in/out data in anyway. If they *did* try to decode the data, then the browser would produce a certificate error, unless the browser had been bundled with a fake cert (how I assumed in my previous reply it was being done here)
TL;DR : It’s still a MITM (though silent based on the browsers coding itself, not a fake cert), and not how any other proxies deal with https connections.
Pingback: Nokia: Yes we decrypt your HTTPS data, but don’t worry about it — Tech News and Analysis
Can you post the full contents of those three certificates (ie, the cert files themselves)? That would help to clear up some questions (for instance, whether the MITM’ed certs are being generated by a CA that is normally trusted by browsers, or whether they are generated by a CA or SubCA that has been configured to be trusted within the Nokia phones themselves. I know that you stated, “When checked trusted certificates in phone it is found that Nokia has pre-configured the phone by trusting at least one of these certificates, which is the reason why there are no security alerts being shown during this Man In The Middle (MITM) attack by Nokia.” However, that doesn’t seem to be the case based on the screenshots.
Hey Steve, as I just posted in my reply to Andy Ruddock (in his reply to me), I think you are correct.
As Andy pointed out, and you mention, the certs themselves ARE valid, it’s just the browser is forcing a connect (not a typical proxying) to the ovi.com servers.
As you point out from the screenshots, the certs are not fake “google.com” certs, but valid certs, for the omi.com subdomains.
Cheers,
Jamie
Jamie,
I think you are misreading Andy’s response. The way I read it is that the browser would always open a SSL connection between itself and the OVI proxy. Then on top of that channel it will build a second session to the final destination.
Take a look at my initial post to understand why this blog post is in no way showing SSL MITM. Also read in more details the _alleged_ Nokia response which technically does not say anything about them decrypting web traffic. It’s written in a way to make people in this forum happy but does not admit to any wrong doing (Nokia dude, correct me if I’m wrong).
Furthermore there is _no_ evidence in this article they are doing any of the alleged MITM.
Cheers,
Pingback: Nokia: Yes we decrypt your HTTPS data, but don’t worry about it ← techtings
From what is currently posted it appears that the HTTPS traffic is intercepted and re-routed to an ovi.com server. This is indeed a MITM, enabled by the browser.
Those servers present a chain of certs that root to a very common Verisign CA. If the browser is implemented like most SSL clients the Verisign root is in the trusted cert store. Removing it would disable SSL to many servers on the internet. So removing CAs from the trusted store is probably not going to disable the MITM.
@Verizon is correct that many carriers try to get phone makers to insert carier-controlled CA certs into their trusted cert store. But the phone companies can resist if they want. Not long ago I was in charge of the trusted cert store for Palm. We did not let the carriers insert their certs, and we were a small manufacturer with little leverage, just a committment to user privacy.
@Nokia, telling customers not to worry it’s all secure is not useful. I’d want independent proof before trusting you with my banking data. Even with proof there is no way to ensure that Nokia’s policies would not change in the future.
Pingback: Nokia Admits Decrypting User Data But Denies Man-in-the-Middle Attacks « University of Wales, Newport: Information Security and Privacy
Pingback: Nokia Hijacking your Phone's Data Traffic ; Nokia Browser Proxy Performs MITM
Nokia Browser works in that way by design and is well know. It uses a proxy server for every translation because the mobile phone alone (and the network band is designed for, India) doesn’t allow a direct web experience.
The proxy contains a real off-screen browser that converts the pages in a semplified version to be sent to the mobile phone. It also caches, reencodes images for the phone with the same exact purpose.
Nokia advertise and document such feature.
So, you just discover the hot water 😉
This is because that phone cannot give to the user a real web experience in another way. Opera MINI does the same.
Wow, just wow, people really don’t get it. Yea, the proxy is in the middle, but that doesn’t mean that your connection to the https site can be read, because the private/public key encryption encrypts from end to end.
Seriously, set up your own SSL MITM attack so that you can see how this really works:
http://mitmproxy.org/
That’s the point – in this case the data to the https site *CAN* be read. It’s working like a web-proxy. The phone makes an SSL connection to the proxy, the proxy decodes the requests and then makes an SSL connection to the final https site. There isn’t end-to-end encryption.
No you are wrong. There are two TLS sessions. One from phone to Nokia and one from phone to browser, via phone to Nokia TLS connection. This is common, normal and secure.
Pingback: Nokia decrypts browser traffic, assures public not to worry | Technophile
I just read your January 11th update. So let’s assume that what they were doing before can fairly be considered a MITM attack (not worthwhile to argue about that). You say, “they are no more doing Man-In-The-Middle attack.” However, the evidence you give is that they are tunneling a bunch of indecipherable traffic over HTTP. But we don’t know what the contents of that traffic is, because as you also note:
“We are yet to try seeing certificate information in this as it is neither available from Phone nor from packet sniff as was possible previously. I am yet to check how is GET/POST requests to a HTTPS site is handled.”
So, all we really know is that they aren’t snooping on traffic in exactly the same way that they were before. The browser could be converting all requests for HTTPS to some encryption scheme/key that is only known to them, but it still readable at their proxy. That’s basically what Opera Mini does: http://stackoverflow.com/a/13154670
http://www.opera.com/mobile/help/faq/#encryption
However, whereas Opera Mini has an arguably good reason for doing this (they do OBML pre-rendering), it seems like Nokia does not. As far as I know, they don’t do any such fancy custom optimizations. Their Nokia Xpress client is Gecko-based.
It would be better if Nokia simply supported direct HTTPS connections. If they really want to proxy SSL traffic, they could do it via SOCKS so that we can verify that this is what is happening.
Pingback: Nokia confirms its XpressBrowser decrypts HTTPS traffic, claims it’s done securely | Better Than Iphone - Samsung, HTC is Better Than Iphone
Pingback: Nokia decrypts browser traffic, assures public not to worry | Gens News
Mate you need to retract your post before you do any more damage.
As I said 2 days ago the entire premise of your post in wrong, and you misunderstand how TLS and proxy servers work.
The tech media is ignorantly reporting on this — you claim to be an expert but you misunderstand how this all works.
Nokia got so scared they turned off the “outer” layer TLS session that you were seeing in wireshark.
They now use plaintext http proxy for the phone to server TLS session.
You have successfully weakened nokias security model. TLS in TLS tunnel that Nokia were deploying offered additional resistance AGAINST interception. (ie Check Point and Bluecoat, etc do not do TLS in TLS interception).
@MIW I don’t really understand your phone/browser/Nokia explanation.
When visiting, eg https://www.google.com, you’d expect to see google’s certificate displayed, which apparently it isn’t,
If all traffic is inside an already encrypted tunnel to nokia, which would require hard-coding in the browser (which I can believe), why is the google cert not displayed to the user?
Are you saying that the browser is “off-phone”, and the phone is used simply as a viewing device (like an xserver)?
Andy,
What are you talking about?! Provide certificate serial numbers and MD5/SHA1 fingerprints.
There has been so much noise in this thread an so far no _technical_ data _relevant_ to the claim.
Is it so difficult to read on PKI and how SSL works?
Cheers,
Nokia claims : « When temporary decryption of HTTPS connections is required on our proxy servers, to transform and deliver users’ content, it is done in a secure manner. »
How you would call « HTTPS temporary decryption » if not a MITM attack ?
If they had been doing TLS in TLS they would have been unable to “transform and deliver users’ content” as Mark Durrant phrased it.
I completely agree, if I was Nokia, I would be having my lawyers give you a call.
Pingback: Nokia confirms its XpressBrowser decrypts HTTPS traffic, claims it's done securely
I wouldn’t call this a man-in-the-middle attack, it’s more like spyware phoning home. The browser is programmed to connect to Nokia’s proxy instead of the server you tell it to connect to. It’s software installed in your device that contacts its masters and reports on what you’re doing. That’s spyware by my definition. If the browser had actually tried to connect to Google directly, and Nokia had been able to intercept and decrypt the traffic anyway, then it would have been a man-in-the-middle attack. But that’s just terminology. It’s equally nasty regardless of what we call it.
I’m relieved to find that my Nokia N900 does not seem to phone home in this way. I tested HTTP and HTTPS and watched the traffic with Wireshark. There were DNS requests for Google’s domains and connectoins to Google’s addresses. There was also an OCSP request to Verisign to check that the certificate hadn’t been revoked, but no attempts to contact any Nokia servers.
Pingback: Nokia Browser Relies on Man-in-the-Middle Tactics to Cut Down on Data Bill | HOTforSecurity
“How you would call « HTTPS temporary decryption » if not a MITM attack ?”
1. The phone’s browser is clearly configured to use a proxy. If the phone were actually beign attacked, an attacker would have had to circumvent the phone’s default behavior to inject the proxy server into the communication stream.
2. The certificates installed on the phone are from trusted roots.
For this to be a MITM attack, Nokia would have to be attempting to impersonate one of the parties on the communication. This is not the case. Nokia’s proxy server is acting as an intermediary between the source and destination. At no point does Nokia attempt to decieve the source or the destination of it’s identity in the SSL chain.
@Andy
> For this to be a MITM attack, Nokia would have to be attempting to
> impersonate one of the parties on the communication. This is not the case.
This is the case. User requested https://google.com. Address bar says https://google.com.
So Nokia impersonated google. Just screwed at hidding it. Now they hide it better.
> Nokia’s proxy server is acting as an intermediary between the source and destination.
In IT security ‘intermediary’ that is not an official party to the protocol is called “an Adversary”
or simply “the Attacker”.
> At no point does Nokia attempt to decieve the source or the destination
> of it’s identity in the SSL chain.
Nokia have deceived its users. The a-bar said ‘google’, connection was to ‘nokia’.
Nokia did not deceived the google, yes. Fortunately EU regulations are quite strict and
crime done by fools is punished exactly in same ways as crime done by smarts.
Pingback: Nokia caught wiretapping encrypted traffic from its handsets ~ Richard Falkvinge « Stop Making Sense
Your update from 11th shows again how you just don’t get it… I’m giving up on you 🙂
Read how proxying works. The only thing I can tell you is that as a result of your “effort” Nokia deleted the extra protection they were giving to people for non HTTPS traffic.
And again, read on openssl and how to use it. The documentation will most likely rise a number of questions which, if you were to google, you would find informative and hopefully you will understand how it works. Apart from that I would recommend Schneier’s book “Applied Cryptography”.
Cheers,
John Lane, I’m eager to understand. Please tell me where I’m wrong :
1. Attempt to connect to https://www.google.com
2. Effective connection to https://cloud13.browser.ovi.com
3. The browser receives a valid certificate for cloud13.browser.ovi.com
4. The server behind cloud13.browser.ovi.com makes a connection to https://www.google.com, thus being the real client browser, as far as google server is concerned
5. Nokia’s server replicate requests and replies between the browser and google
In this scene, the browser don’t even see google’s server. And google’s server don’t see the client browser. There is no need to forge a false certificate to present to the client browser.
If there was an HTTPS tunnelled connection between the client and the server through the HTTPS one between the client and the proxy, the client should see the real server certificate, and the real server address. Isn’t it?
OK. So, this is not a MITM. This is proxying HTTPS without informing the user. Information is encrypted between client and proxy, and between proxy and server but the proxy server see the stream unencrypted. It’s not something I would like from any proxy I use.
Or is there something I don’t understand / missed?
Pingback: Nokia decrypts browser traffic, assures public not to worry | Technology and Gadget News
Reblogged this on University of Wales, Newport: Information Security and Privacy and commented:
Nokia Man in the middle hacking attack against HTTPS
Pingback: Nokia Caught Exposing User Data To Potential Snoops | ImpressiveNews
FWIW, I did my own investigation and provided thoughts here:
https://freedom-to-tinker.com/blog/sjs/how-the-nokia-browser-decrypts-ssl-traffic-a-man-in-the-client/
I address several of the disputes that have arisen here in the comments… hopefully accurately.
Pingback: Nokia Caught Exposing User Data To Potential Snoops | The Business Defense News Network
Pingback: Nokia onderschept https-bezoeken gebruikers S40-telefoons | Techzine
Pingback: Nokia confirms their XpressBrowser decrypts HTTPS traffic, but states that it's secure | Mobile Phone News, Reviews and More
@John Lane, @Miw, @others, who still do not get what the MITM is.
Secure connection means that all traffic is encrypted between TWO points.
‘Originating’ and ‘End’ ones. Lets name said points “Alice” and “Bob”.
Encryption is engaged to ensure, that no THIRD party can read messages flowing
between Alice and Bob. Third party is by convention called Mallory. “M” as in “Middle”.
If a THIRD party, placed BETWEEN the Alice and the Bob, is circumventing anything
(be it browser, certs chain, key agreement) to get its hands on plaintext traffic,
it is called “Man In The Middle Attack”. Period.
No magic blah-blah-its-in-secure-way can change reality:
It is Man In the Middle. In this case its “the NOKIA In The Middle”.
MITM, because Mallory can read plaintext.
It is an ATTACK, because neither Alice nor Bob wanted Mallory (Nokia)
to read their communication.
Whole SSL architecture was thought and done exactly to protect traffic between Alice and Bob from Mallory’s prying eyes. This particular ATTACK was performed by implanting “no warn” certificates.
It might be by leaking session keys on side channel. In fact it might be performed in multitude of ways, as it was done within closed source client.
No one need to dig into how, or if at all, PKI infrastructure was exploited here:
THIRD party sitting in the middle and reading message that was meant only for
TWO parties is a schoolbook, plain, MITM Attack.
P.S. In EU countries, doing such MITM is an criminal offence. I am about to make formal reporting it to the authorities. I hope that EU regulators and authorities will do huge showcase on it.
Has anyone tried using a client cert authenticated service from their Nokia phone? It shouldn’t work, since the middle man (Nokia’s) server wouldn’t have the private client key… Just curious.