3G/4G IP Address Changes when Switching from HTTP to HTTPS

If you have an authentication scheme that relies on some level of the client's IP (Internet Protocol Address) maintaining state during the process then you should be aware of the potential that the client IP is different between regular HTTP and HTTPS (Secure HTTP) when that client is accessing from a 3G/4G data network. A real world example: on the first request/page-view on HTTP, you may see the client IP as 166.137.82.247 and on the second from HTTPS you may see 166.137.88.49.

Often an authentication scheme will use that IP address as a partial internal key or as additional verification to increase security and limit DOS (Denial-of-Service) attacks. An authentication scheme that relies on that IP address remaining the same at any given point, will have to be adjusted for the behavior of phone data networks.

Possible Solutions

There are four strategies to adjust.

Remove IP Address Dependency

First, if reasonable and not truly needed, is to adjust the scheme to abandon IP address as a key or verification step altogether.

Use HTTPS for All Requests

The second, noticeably adopted by many sites, would be to use HTTPS for all requests/page-views after initial log-in. In that case, all the requests end up coming from a constant IP address.

Maintain HTTP to HTTPS Mapping

The third alternative is to maintain the mapping from HTTP-IP-Address to HTTPS-IP-Address back to HTPP-IP-Address. In this case, the scheme would consider that a valid transition if it ends up back where it started from. Any transition in a reasonably short time frame would not be suspect.

Match on Class B

The forth option is to loosen the rules of IP match to only use the first two octets of the IP address to match. In other words to only key off the Class B. So in the above example, 166.137.*.* does indeed match 166.137.*.*. Again, any authentication across a Class B in a reasonably short time frame would be considered valid.

Moreover if you are using a Geo IP look-up database already when servicing a request then for both the third and fourth options you can also only allow that variant behavior from those known data networks.

Metrics Opportunity

As an interesting aside, if one was so inclined to try to measure how many users are actually using a given resources from a data network, even a service that doesn't normally use HTTPS, then one can send a small request, such as an pixel/web beacon, to your service via HTTPS and see if the IP address in that request matches the IP address in the base HTTP. The ones that don't match are extremely likely to be from devices on a data network.