Over the past couple of days there has been some press coverage over security researcher Guarang Pandya’s report that the browser on his Nokia phone was sending all of his traffic to Nokia proxy servers, including his HTTPS traffic. The disturbing part of his report was evidence that Nokia is not just proxying, but actually decrypting the HTTPS traffic. Nokia replied with a statement (in the comments section of Pandya’s blog post, and to several news outlets):
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.
So, it turns out that Pandya was correct: Nokia is decrypting SSL traffic in their proxy servers. This is not disclosed in their privacy policy, and the somewhat vague assurance of things being done “in a secure manner” is not entirely comforting. Beyond that, the statement gave some other interesting clues. One clue was that this is a feature of the Nokia Xpress Browser, an app that is available for the popular Nokia Lumia phones that run Windows Phone 8. These phones are available from the major US carriers, whereas Pandya’s phone (the Asha) is mostly sold abroad. So I tracked down a Lumia phone, installed Nokia Xpress, and did my own investigation. Results after the jump.
How is SSL Decryption Possible?
Pandya’s evidence that Nokia was performing what amounts to a man-in-the-middle attack was a packet sniffing session in which he browsed to https://google.com and observed that the certificate being passed to his phone was for the domain “cloud1.browser.ovi.com.” That is abnormal and troubling. The certificates should be for “google.com.” He posted some screenshots of the certificates, but I managed to pull out the actual contents of the certificate via my Lumia phone running Nokia Xpress. The geeks can view it here. For whatever reason, this one was issued to “wp.browser.ovi.com”, but you can see that it chains up to a trusted Verisign root by way of intermediate Verisign certificates:
Issuer: C=US, O=VeriSign, Inc., OU=VeriSign Trust Network, OU=Terms of use at https://www.verisign.com/rpa (c)10, CN=VeriSign Class 3 Secure Server CA – G3
Validity
Not Before: Jun 20 00:00:00 2012 GMT
Not After : Jun 21 23:59:59 2013 GMT
Subject: C=US, ST=Illinois, L=Chicago, O=Nokia, OU=OVI Browser, CN=wp.browser.ovi.com
It was also clear, based on my own packet sniffing, that HTTPS traffic intended for https://freedom-to-tinker.com was going to wp.browser.ovi.com. In our server logs, I witnessed the requests emerging from the other side of the Nokia proxy system:
64.27.165.35 – – [10/Jan/2013:22:13:01 -0500] “GET /wp-content/themes/education/images/rss.png HTTP/1.1” 200 526 “-” “Mozilla/5.0 (Series40; Nokia311/05.60; Profile/MIDP-2.1 Configuration/CLDC-1.1) Gecko/20100401 S40OviBrowser/1.8.0.50.5”
(Note, the connection being made here is an HTTPS connection–that is all that our server accepts). All of this simply confirms what Pandya observed, and what Nokia admitted. But what would cause this behavior? You would expect your web browser to receive certificates for the secure web site that it claims you are connected to. Apparently, Nokia browser on Pandya’s phone, and Nokia Xpress on Windows Phone 8, translate your requests to secure sites into requests to the Nokia proxy server before it ever leaves your phone. Commenters on Pandya’s post have been arguing about whether this constitutes a “man-in-the-middle” or not. I suppose that it’s more of a “man-in-the-client” that supports the second “man-in-the-middle” on the proxy.
Is that what’s really happening?
There could have been a less disturbing explanation of this behavior. It could have been the case that Nokia was simply tunneling HTTPS over HTTPS–that is, they took your request for https://google.com and left it unchanged, but wrapped in in another layer of HTTPS to be sent to their servers. This would maintain end-to-end encryption, while performing a traditional proxy role. The evidence that Pandya gathered and that I verified does not conclusively tell us whether this is the case, but Nokia’s public statement seems to indicate that the more troubling version of events is occurring: “When temporary decryption of HTTPS connections is required on our proxy servers, to transform and deliver users’ content…”
Isn’t this the same as what Opera Mini is doing?
There is an increasing trend to build simplified browsers for mobile devices in which optimizations are done by a proxy server. Silk for the Kindle Fire is an example, but Silk doesn’t perform proxy decryption of SSL connections. Opera Mini is another example. Opera Mini is a version of the Opera browser, designed for lower-performance mobile devices, that sends all traffic through Opera proxies. These proxies do extensive pre-processing of web pages, and return a highly optimized version of the web page via a standard called OBML. This includes SSL traffic, for which there is a similar “man-in-the-client” that sends SSL-destined traffic to the Opera Mini proxy encrypted with keys that the proxy knows and can decrypt. Opera got significant flak for this, and has since gone out of their way to explain on their web site that “If you do not trust Opera Software, make sure you do not use Opera Mini to enter any kind of sensitive information.” However, when I installed the Opera Mini browser on my phone, I wasn’t pointed to those warnings. I saw the Opera Mini EULA, and the Opera Mini Privacy Statement, which do not include such language. So, as opposed to Nokia, Opera has made an effort to alert users to the browser’s SSL decryption–although I think they could do much better. Opera also may have a more compelling case for why they need to do this interception. Their browser only understands OBML, not HTML. It wouldn’t know what to do with the HTML contents of a non-intercepted SSL connection. It’s not clear to me how Xpress works internally, but the user-agent coming through their proxy declares it to be a Gecko-based client, which is built to render HTML.
To be clear, I think that any “man-in-the-client” SSL interception is a bad idea. I don’t think that engineers should sacrifice security in the name of efficiency in this case. If it’s not possible to maintain end-to-end encryption with the given technology, then the engineers need to think harder about how to tweak the technology to make it possible. However, where it is done, it’s clearly better that it is prominently disclosed.
What does Nokia Xpress communicate to the end user about all of this?
When installing and using Nokia Xpress, I took the following two screenshots. The first is the initial user agreement page, which as of 9:24pm Eastern time last night included the somewhat-cryptic sentence, “Https connections will be decrypted in a secure manner.” I wonder if this is part of Nokia’s attempt to “review the information provided in the mobile client in case this can be improved,” and I wonder if this sentence existed a week ago. It’s certainly not transparent what they are referring to, and as an end-user it would not be at all clear to me what this means. Which HTTPS connections? I would expect that the client would decrypt my HTTPS communications with Freedom to Tinker in a secure manner, but I don’t think that’s what they intended to convey.
The larger story here is that as more of our communications move to mobile devices and to the cloud, we will encounter surprising exceptions to our expectations for secure communications. Browsers like Nokia Xpress and Opera Mini are essentially moving our web browsing to the cloud–pushing the security functions that we traditionally thought existed in a safe zone within our device to far-away servers. At the same time, our devices can betray us by aiding and abetting this security offloading. This was one of the messages of Jonathan Zittrain’s recent talk at CRYPTO 2012, “The End of Crypto.” His title was a play on words, and in the latter half he emphasizes the “Ends” of crypto. His message is that security of the end-points will be increasingly important in a networked, mobile, and cloud-based environment. The broad lessons are twofold:
1. What happens “in the cloud” is increasingly relevant to privacy and security
2. What happens “on the device” (especially mobile) is in flux, and misunderstandings or missteps can be risky
At such a high level, these may seem like a no-brainer. They are no surprise. That being said, specific cases like Nokia’s SSL decryption are quite surprising indeed.
Without a standard allowing the client to request compressed/bandwidth-optimized content directly from the server, HTTPS MITM is the only way to reduce the amount of data transmitted to the client. It’s a tradeoff that is reasonable in many cases where the information is not especially sensitive, and considering that many websites encrypt by default even when there may not be sensitive data. So long as the user is aware, and the server-side implementation is secure, this isn’t much worse than the trust the user places implicitly in browser manufacturers by their choice of certificate roots bundled into the browser.
Perhaps it is acceptable if the user is aware, if the user has the ability to opt-out, if the host site is also aware, and if the browser vendor is exercising reasonable care (perhaps backed up by audit and/or third-party security testing). Perhaps.
As a broader policy matter, creating another point of potential security failure while doing non-standard things with HTTPS seems like a bad idea. I understand the idea of a performance tradeoff, especially in the case of less powerful “feature phones” on slower networks, but the trend to push these “thin” HTTPS-hijacking browsers into high-powered smartphones on high-speed networks seems extremely short-sighted.
A major problems in the mobile device world is that a single vendor may play most or all of the following technical roles in the supply and service chain: (1) specifying the hardware, (2) customizing and installing the OS, (3) customizing and installing the default browser and mail programs, (4) acting as the supplier and moderator of all other “app” software, (5) acting as Internet service provider, (6) acting as firewall/proxy server, and (7) now we know, acting as certificate authority.
In the PC world these same technologies and services are generally provided by different companies, and there is some competition and choice in each of them so that the user can at least in principle make those choices. But there is severe vertical technology integration and very limited competition in the mobile device world that largely prevents that kind of user control and choice. Under those circumstances it is hard to argue that anything you do on a mobile device can be secure against threats from whatever company dominates the software stack and service provision of your device.
If you think about it, any Content Delivery Network (CDN) is doing the same since many years. It is easy to realize this when using the CertificatePatril Firefox extension, that keeps issuing warnings of changing CA when connecting to the same web site. The warnings are often due to the CDN.
This is very different from the CDN certs that you see. The CDN has a valid cert for the domain in question, presumably because it or the private key was given to them by the owner of the domain [edit: or, I should note, a CA could “receive permission from each domain holder to include their FQDN in these certificates“]. Cert Patrol is being laudably paranoid, but in this case, it’s not reflective of any actual attack. The end user is accessing the hosts content in an end-to-end fashion, without interception or decryption along the way. The host has just chosen to make some of that content available via a CDN, and in order to do so has handed over the key [edit: literally, or figuratively]. See more here:
http://security.stackexchange.com/questions/23042/why-is-this-certificate-valid-for-so-many-domains
The Nokia stuff is entirely different. The client software is mangling SSL requests in order to send them not as normal SSL requests but instead as Nokia-readable encrypted requests, which are indeed decrypted at the proxy. This breaks end-to-end encryption.