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
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
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
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
From some angles, this looks like a classic "man-in-the-middle"
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:
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.
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.
to post comments)