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.
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:
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:
126.96.36.199 – – [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/188.8.131.52.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.