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 ?
The CRIME attack relies on the ability for the attacker to insert some hostile Javascript in a page which the client loads, and to observer the data streams that emerges from the victim's browser and is directed towards a target server. This usually means that the attacker must be close to the victim or close to the target server. In our case, the SSL-with-compression is between the mobile phone and Nokia's server, and we assumed Nokia's local network to be honest and clean. Thus, the attacker must act in the vicinity of the victim.
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.
WiFi is known to be susceptible to the redirection tricks that CRIME builds on. This is especially easy here: the attacker just runs an open WiFi hotspot. Phones in the immediate vicinity will see that hotspot as having a very clear signal, and will connect to it. If all data packets go through the attacker's hotspot, it becomes easy to intercept an HTTP page load, insert the hostile Javascript payload, and then run CRIME. Endgame.
If the smartphone uses 3G, things become harder. Javascript payload insertion can be envisioned with various tricks (e.g. with a HTML email or things like that). The part about observing the SSL-encrypted stream is harder, though. 3G connections are encrypted, normally with the KASUMI block cipher. An important point is that CRIME is all about the length of encrypted data. It is not strictly necessary to see the SSL records; the attacker just need to know the length of these records. The fact that the records will be encrypted with KASUMI does not hide their length (especially since, in UMTS, KASUMI is used in counter mode which means that it preserves the length of the data which is encrypted, with bit-level accuracy). Trickier would be the frame granularity: radio networks split data into individual, atomic frames, which hides part of the length information that the attacker needs. It can be repaired, though, with phasing: the attacker alters the length of his hidden requests so that the compression is at a threshold (that is, compression success, meaning one more cookie byte guessed, implies a SSL record which uses one less frame). Fine tuning would probably be a matter of delicacy.
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.
4. Conclusion
Was Nokia's "institutional MitM" vulnerable to CRIME ? Probably.
Did their recent upgrade fixed that ? Probably.
Is Opera Mini also vulnerable ? Probably not because it is an off-loaded rendering, which means that Javascript does not run on the browser itself, but on the server. But a CRIME variant might still be applicable.
