HTTPS interception in Nokia's mobile browser

When using encrypted communication, users are at the mercy of the software that implements the cryptography. That generally works out reasonably well; users are only exposed to inadvertent bugs present in the code. But a recent report shows that sometimes using encryption may not actually result in more secure communication—such security depends on having tools that are actually trying to do what is expected of them.

When a user visits an HTTPS site, they expect their browser to use an encrypted connection between it and the web site. Truthfully, many users are not technically sophisticated enough to understand that, but they have been (hopefully) trained to trust in the "lock" icon or other user interface elements that indicate a secure connection. Whether the user knows that means "encryption" or not depends on their level of technical savvy, but they almost certainly don't expect their secure data to be sent to a third-party server. But that's evidently what Nokia's Xpress mobile browser has been doing.

HTTPS traffic is encrypted using keys that get exchanged between the destination server and client browser. A public key is contained in a server certificate that is signed by someone—typically a certificate authority (CA). The signature asserts that the key belongs to that server name. The public key is then used to encrypt and exchange session keys that are subsequently used to encrypt the session. The CA is integral to the web browser trust model; keys that don't validate under that model (e.g. keys signed by unknown or untrusted CAs, server names that do not match, etc.) are expected to cause some kind of alert from the browser.

So it came as something of a surprise to security researcher Guarang Pandya that both regular HTTP and encrypted HTTPS traffic were being re-routed when using the Xpress browser. Worse yet, the certificate presented for any site visited was not that of the site in question, it was, instead, an ovi.com certificate. Ovi is Nokia's "brand" for its internet services.

From some angles, this looks like a classic "man-in-the-middle" attack, but because the browser is complicit, Steve Schultze of the "Freedom to Tinker" blog calls it a "man-in-the-client". The man in the client is accepting a certificate for a Nokia proxy server instead of the site the user wanted to connect to, without notifying the user. Meanwhile, the man in the middle lives at the Nokia proxy server, which is making a connection to the desired destination.

The proxy is used to speed up mobile browsing by using compression. It is similar to what is done by the Opera Mini browser, which Pandya also noted in his first report. But, Nokia was also using the proxy for HTTPS traffic, which meant that it was decrypting the incoming stream at the proxy and re-encrypting it, using the real destination's key, before sending it onward.

Decrypting the HTTPS traffic from the mobile browser was not necessarily required, depending on how Nokia implemented things. It could have just relayed the traffic between the two endpoints by tunneling the traffic inside a client-to-proxy session. That would not have required decrypting the traffic, but it also would not have allowed the proxy to do its compression on the data, obviating the need for the proxy.

Nokia, however, admitted that it decrypted the traffic in a comment by Mark Durrant on Pandya's post:

The "secure manner" phrase does not completely reassure, but this does not really look like an attempt to (knowingly) invade users' privacy. Durrant noted that Nokia has "implemented appropriate organizational and technical measures to prevent access to private information". It seems quite likely that this was simply a misstep by the company—one that could lead to a loss of privacy for Xpress users.

That interpretation seems to be borne out by changes that Nokia made to the Xpress browser after Pandya's report. After a browser update, Pandya noted that HTTPS sessions were not being handled in the same way. The HTTPS traffic is now tunneled over an HTTP connection to Nokia's servers, and the certificate being used (at least as reported by the browser) is the proper one for the destination. So, only the destination endpoint should be able to decrypt the data. Given that, though, it's not clear why the proxy is not just bypassed for HTTPS traffic.

The "welcome" notice that comes when installing the Xpress browser does make note of HTTPS decryption, though Schultze wonders how long that's been true, but certainly doesn't fully describe what's going on. Many users are likely to gloss over that statement—or not understand it at all. While web compression is a helpful feature for some users, it shouldn't come at the expense of reasonable security and privacy expectations.

As more of our traffic moves into "the cloud", we will be seeing more of these kinds of problems. Investigations like Pandya's will be needed to ensure that we at least know this type of network manipulation is occurring. Open source mobile operating systems (or even just open source browsers on proprietary systems) make it easier to find and eliminate this kind of mistake, but vigilance is needed there as well. Reviewing the code and ensuring that the "app" corresponds to the code reviewed are still required. With open source, though, we can peek inside the black box, which should make things easier—though not foolproof.