29

While testing a recent adtech integration I noticed something I can't explain. The iPhone uses two IP addresses. Seemingly one for HTTP and one for HTTPS. To further confuse things it only happens when the device is not on wifi. Although, the only carrier I've confirmed it happening with is AT&T. FWIW, this does not happen with Verizon

Can anyone explain why this would be the case?

Example: http://ipof.in/json returns a different IP address than https://ipof.in/json. They appear to be owned by the same carrier (AT&T), as well as both public, but are wildly different (107.77.212.XXX vs 166.216.157.XXX).

It's also worth noting that the response from ipof.in contains a timestamp. Nothing is being cached. I receive similar results with similar service www.ip4.com, etc.

Monty Harder
  • 476
  • 3
  • 6
Greg Dean
  • 392
  • 3
  • 7

2 Answers2

45

I am just going to take a guess here. Your telephone data carrier may have an optimizing or caching proxy for content whose IP address appears in your JSON result. As the proxy has no visibility into encrypted HTTPS packets, it cannot proxy the content, so it may be routing directly with your public (routable) IP address.

If this is the case, your phone has one IP address but the carrier's routing shows different origin IP addresses at ipof.in.

Akber Choudhry
  • 809
  • 7
  • 12
  • 16
    Seems like a proxy is there. I checked my request header and noticed I get *Via: cncnz03msp2ts05.wnsnet.attws.com* So ATT has some massive proxy that is proxy all HTTP traffic, yikes! furthermore, it's not including the X-Forwarded-For header – Greg Dean Jun 21 '16 at 07:29
  • 11
    Proxying is probably the nicest thing AT&T is doing to your unencrypted data. I would expect them to do all sorts of packet inspection and header enrichment if they can get away with it. – You Jun 21 '16 at 17:23
  • 5
    @GregDean: Your data is quite obviously already *entirely* going through their equipment... why does seeing a proxy header make you freak out? – user541686 Jun 21 '16 at 18:17
  • @You They used to add tracking headers, but stopped in 2014 https://www.eff.org/deeplinks/2014/11/att-ditches-tracking-header-program-verizon-still-refuses – Jon Jun 21 '16 at 18:20
  • @You fair point. Seems more personal at the HTTP level. Maybe its the fact that they are dealing with application data not just routing/network data. Also, I would feel better if they included the X-Forwarded-For header, to preserve the original request – Greg Dean Jun 21 '16 at 18:38
  • @GregDean routing is boring. Looking at application data (all kinds) to do service-aware charging, header enrichment and so on is where the money is at. If you want your data private, set up a VPN tunnel terminating with some ISP you trust (my impression is that regular ISPs do a lot less packet inspection and stuff). All your plaintext cellular traffic will be subject to this stuff. – You Jun 21 '16 at 20:01
  • 2
    @GregDean: `X-Forwarded-For` is not intended for usage like this. The ip address it did the forwarding for is likely on a private block and thus meaningless to the server, and moreover, `X-Forwarded-For` cannot be trusted (and thus must be ignored/stripped by your server anyway) unless it's generated by proxy you or someone you trust controls on the server side (think load-balancing proxies like haproxy or a service like CloudFlare). – R.. GitHub STOP HELPING ICE Jun 21 '16 at 21:04
  • You may find interesting that these nasty proxies violate your privacy by (unintentionally) leaking your phone number to any app you use, assuming you ask nicely with the correct headers. – André Borie Jun 21 '16 at 21:18
  • @AndréBorie How do the proxies leak your phone number? – WillS Jun 21 '16 at 21:53
  • 1
    @r the IP address is likely they same IP address that is seen over HTTPS, so not private. I don't see the harm in including XFF and letting the destination server make a decision on trust. – Greg Dean Jun 21 '16 at 22:28
  • @WillS it's part of their "header enrichment" nonsense, they want to "help" you by for example logging you in automatically when you're browsing their site from your mobile connection. The proxy detects you're browsing their site if it sees an HTTP connection there, and adds a custom header with your phone number into the request. The issue is that some proxies merely check the Host header (and not the actual destination IP), which means you can POST to evil.com, set Host to the carrier's site and evil.com will get your number. Advertiser's heaven right there. – André Borie Jun 22 '16 at 10:27
5

Your HTTP requests are proxied, hence the ipof.in service sees different IP addresses.

I believe this answer explains it well, but another possibility (regardless of cellular/WiFi connection) is that your browser uses a Data Saver (Chrome*) or Turbo Mode (Opera) option. Both intended to compress the data for mobile devices.

* Chrome feature seems not available anymore for iOS. It could be turned off to get consistent results. Visual instructions for old Chrome (Settings -> Advanced -> Bandwidth -> Data Saver and switch the option to Off) are here starting from slide 5.

Community
  • 1
techraf
  • 9,141
  • 11
  • 44
  • 62
  • That's what "another possibility" means. Try Chrome and see it works exactly the same as you described, including unique timestamps. – techraf Jun 21 '16 at 05:41
  • 1
    And the word *proxying* is not the same as *caching*. – techraf Jun 21 '16 at 06:42
  • But you did not ask "guess what I'm doing", right? You asked "Can anyone explain why this would be the case?" That would be the case if you used Chrome, so I answered. I clarified your concerns about caching and Chrome in iOS. I also wrote that most probable cause in your case is explained in the other answer. Can I do something else? – techraf Jun 21 '16 at 07:18
  • 1
    Surprisingly this feature is **no longer** available on iOS not "not yet available". This is how it worked - [starting on slide 5](http://www.phonearena.com/news/How-to-activate-Chromes-Data-Saver-feature-on-Android---iOS_id69090) – techraf Jun 21 '16 at 09:48
  • 2
    Wouldn't a browser proxy work the same on wifi and cell data? – Greg Dean Jun 21 '16 at 10:56
  • Yes, it would. That's exactly what I meant by "regardless of cellular/WiFi connection" in my answer. – techraf Jun 21 '16 at 10:59
  • 1
    and exact what I mean with "it only happens when the device is not on wifi" – Greg Dean Jun 21 '16 at 11:11