Nokia 110 4G MITM (Opera Mini)

I bought a Nokia/HMD 110 4G 2023. It has a 120x160 1.1” display, and (for some reason), a browser. But the browser is interesting.

Opera Mini

Opera Mini is a surprisingly popular browser. Probably, sadly, unfortunately, one with more users the Firefox. Its success largely comes from developing nations that make heavy use of cheaper phones with limited processing capability, and the fact that Opera Mini performs compression on payloads to slim-down sites.

HTTP

How it does that compression, is the thing I’m interested in. Back in the days of EDGE, implementing a forward proxy was straight forward:

UAC    --(HTTP req A)---> Proxy --(HTTP req B)---------------> Server
Server --(HTTP resp B)--> Proxy --(Compressed HTTP resp A) --> UAC 

Everything is honest and unencrypted. Of course, you run the risk of that proxy changing the response in a way that isn’t just compression, but if you don’t trust the proxy, I don’t know why you’d trust the equally proprietary browser.

HTTPS

You may think HTTPS changes this. And in theory, it could. There’s nothing stopping the proxy sitting in the middle running TLS passthrough (effectively operating as an L4 proxy instead of L7). But given the selling point of Opera Mini is compression, and non-content-aware compression can’t match content-aware compression, I’m skeptical they’d be doing this.

In practice, what’s far more likely (and was certainly admitted by Opera back in the 2000’s - I doubt this has changed), is that their proxy performs TLS termination. But that begs the question, how is the proxy serving requests for (as an example) piconet.co.uk, given I have the certificate for that domain, but they don’t.

The following are assumptions I’m making about how their proxy works.

• All domains resolve to a pool of proxies, and opera are serving an invalid (in terms of the chain of trust) certificate, and the browser has been programmed to simply accept their certificate.

• Opera Mini may alternatively be rewriting requests so the certificate the proxy uses is valid. Say ‘https://piconet.co.uk/hotdog’ is being rewritten to ‘https://operaproxy.com/url?=piconet.co.uk/hotdog’.

• Opera Mini may selectively skip the proxy, when the proxy’s last response indicated either the response pre-compression was trivial in size, or when compression made minimal difference, or when Opera would expect the compression they apply to make minimal difference (i.e. piconet.co.uk/cob/include/assets/ladder.opus).

• Opera Mini may support AMP, and may maintain a list of AMP-serving domains. I don’t know much about AMP, but it does seem to handle some of the concerns Opera Mini addresses.

Testing these assumptions

So, this is the fun part:

1. I can’t dump traffic on the phone, it’s something based on Nuculeus RTOS, and highly locked-down.

2. I can’t dump traffic on the home router, because the phone doesn’t have Wifi.

3. I can’t dump traffic further up the chain, because I don’t work for Giffgaff/O2/AA/Opera.

4. There exists no clear way to tell if TLS passthrough is being used when my server receives a request from Opera’s proxy.

But what I can do, and maybe will do:

1. See DNS requests for a domain I manage. Which would let me see if the phone itself is trying to resolve my domain.

2. Set up an eNodeB with internet access, and fish out both the location the request is sent to, and the certificates sent in response to the HTTPS request made by the phone.

3. Set up an SDR and catch GPRS/EDGE/UMTS/HSPA traffic, crack it, and then fish out the location/certificates.

4. Embed an image in a site that when compressed with file-type-aware compression, changes appearance so much that I can tell on a 1.1” 120x160 display. A sort of canary.

5. Some other form of canary that would indicate a page, when passed through Opera’s proxy, has changed. I’m vaguely aware IE implement a document.fileSize property.

6. Get into S30+ OS. I do know people have managed to compile binaries for the older MAUI-based S30+ phones - these, not so much.