In the system used by Nokia, the Nokia server runs a man-in-the-middle attack (Nokia denies it because they really do not like the term "attack", but this is still, technically, a MitM). Their servers obtain, even so briefly, the decrypted data. Therefore, if Nokia is the attacker, then Nokia wins, and has no need of playing elaborate games like the CRIME attack. Therefore, in this answer, I assume that Nokia is an honest player and that their servers are not hacked into. The question is: can an outsider run a CRIME-like attack on the mobile browsers without hijacking Nokia's servers ? This depends on several things.
But first, we must note that Nokia's browser has been updated and the new version (as of January 11th) no longer runs a MitM on HTTPS connections. This is probably in response to the news items about their use of MitM, which are "bad public relations" and thus needed fixing. Therefore, all I say below must be understood with an implicit past tense: this does not apply anymore.
Also, note that I do not own a Nokia phone, and I am here making inferences based on what has been described "on the Web", in particular Gaurang K Pandya's blog.
1. How is the interception performed ?
When doing a systematic proxying of Web traffic, there are several ways to do it. One way is to define your own protocol between browser and proxy, possibly quite different from the usual Web standards (HTTP and HTML). This is what Opera Mini does: the page rendering is done on the Opera server, and the result is sent to the browser.
Apparently, Nokia's browser does not work like this. Instead, the network traces obtained with Wireshark show that the connection between the browser and Nokia's server is a perfectly normal SSL/TLS handshake. Moreover, the proxy generates a fake server's certificate, issued by a special CA which the proxy controls. That the proxy even bothers with building a fake certificate means that the browser will validate that certificate as if it was a normal certificate. Analysis of the DNS queries shows that the browser does not try to obtain the IP address for the target server, but only for Nokia's server, which the browser knows under its true name. This strongly hints at the following setup:
- The browser is a "normal browser" and does not implement a special proprietary protocol.
- The browser is configured to use Nokia's server as a generic proxy (with the
CONNECT method described in RFC 2817, sections 5.2 and 5.3).
- In the set of "trust anchors" known by the browser, to validate server certificates against, is the "special CA" controlled by Nokia.
This kind of setup makes sense, economically speaking, because it allows reusing existing protocols and software; and, to a large extent, it allows switching back to non-interception on the server without changing anything on the clients. (That Nokia actually pushed an upgrade is a bit weird; apparently, they now tunnel SSL through HTTP with a yet unspecified protocol; this deserves further investigation.)
2. What kind of compression ?
Assuming that the browser is a "normal browser", then it would make sense that the use of compression follows a standard scheme. There are two standard ways to apply compression on HTTPS traffic:
Compression at the HTTP level. The body of requests and responses can be compressed with some algorithms, usually "deflate" and "gzip" (the latter being a very light wrapper over the former, they offer almost identical compression ratios -- see RFC 1951 and RFC 1952).
Compression at the SSL level. This one applies on every applicative byte sent through the tunnel; in particular, in the case of HTTPS, it covers both request headers and bodies. There again, "deflate" is used.
SSL-level compression is both simpler to implement (because you do not have to parse HTTP headers for that, you just compress the bytes -- and usual SSL libraries already support it out-of-the-box) and is likely to yield a better compression ratio (because, contrary to HTTP-level compression, it can exploit repeated sequences between successive headers and bodies), I deem it plausible that Nokia used SSL-level compression.
It could be verified by anybody with a Nokia phone (i.e. not me)(and not a phone which has been upgraded in the last few days). SSL-level compression is activated during the initial steps of the handshake, so it would suffice to have a look at the
ServerHello message from the server: there is no encryption yet at that point. Wireshark can do that.
Of course, plain SSL-level compression is exactly what the CRIME attack needs.
Thus, my tentative conclusion is that it is plausible that the Nokia MitM/compression system leaves the browser vulnerable to the CRIME attack (actually, left it until two days ago, when they changed their system).
3. Can the attack be really executed ?
Gaurang K Pandya uses WiFi: his phone acts like a basic laptop computer or tablet. Many smartphone users use WiFi whenever possible, because it is cheaper (WiFi usage does not count towards the monthly 3G quota), often faster, and possibly lighter on the phone battery. Thus, many smartphones can be configured to look for open WiFi networks, and/or WiFi networks for which credentials are known, and to use the 3G network only as a fallback.
Also, 3G interception means using a scanner and recognizing the target smartphone packets within the noise. Phones hop frequencies very frequently, and following one specific phone entails knowing where it will jump next, and that information is encrypted. I do not know enough about 3G to know whether this would be surmountable in the context of the CRIME attack.
Was Nokia's "institutional MitM" vulnerable to CRIME ? Probably.
Did their recent upgrade fixed that ? Probably.