Results 1 to 3 of 3
  1. #1
    Untanglit TheDude's Avatar
    Join Date
    Dec 2017
    Location
    Missouri
    Posts
    17

    Default Android re-authentication issue

    I am not sure if this is a problem with SSL Inspector or Captive Portal. However, Captive Portal is a solution in a sense. Any help would be greatly appreciated.

    Client: Android Android 7+
    Notes: All proper google domains are ignored from ssl inspector (and then some), proper ssl certs generated and installed. Everything looks good.

    Scenario 1 Captive Portal Disabled - Android client connects via Wi-Fi and android connectivity check fails displaying X over Wi-Fi icon. Android reports no internet however the device does indeed have internet connection but google services are limited. Everything works with the exception of connections to Google Home devices. Google Home speakers will not communicate with Home App. In this scenario, I receive abandoned ssl error pertaining to one specific ssl cert that resolves back to 1e100.net domains. The certificate ID is always the same but the ip will change. All other google services are operational in this scenario. Android device always reports no internet connection.

    Scenario 2 Captive Portal Enabled - Android client connects via Wi-Fi, session is redirected to captive portal. Click Continue and android connectivity check PASSES. At this point everything works. SSL Inspector does NOT throw any certificate errors and all services work properly. Google home devices connect without any problem as well as all other google services. The session continues without problems for the duration of its connection. Non-ignored google traffic is properly inspected and Life is good as it should be.

    Scenario 3 Captive Portal Enabled with client reconnection Android client has authenticated with Captive Portal and everything is working as expected. At this point, I disable Wi-Fi then re-enable Wi-Fi. Android client reconnects and we are rite back to the Scenario 1 problems. Android client connects via Wi-Fi and android connectivity check fails displaying X over Wi-Fi icon. Exactly the same problems as Scenario 1.

    After Scenario 3, if you kill the Captive Portal session in admin and reconnect the client you are then redirected to the captive page. Click Continue and you are back to Scenario 2. Life is good and everything works as expected until the client disconnects again.

    I am not real sure what to make of this. It appears that Captive portal is allowing some connection to be made by the android client that allows proper ssl inspection. It also seems that the client/server captive portal handshake is not taking place properly on a reconnect.

    I can reproduce this on multiple android 7+ devices.

  2. #2
    Master Untangler
    Join Date
    Mar 2017
    Posts
    189

    Default

    Hmm, seems quite similar to what I've experienced with lots of different phones with different WAPs and authenticator. It's never been that. It's always been - in my cases - problem with how Android itself check connectivity. There are tons of different domains that the operating system tries to connect to to display an X or not on the wifi icon. And they're chosen with a mad round-robin-like method, depending on DNS and first probes. I've seen it probe google domains in the Far East Asia while travelling in South Europe

    Sometimes I had the X, but I could use wifi without issues Fail one probe, you'll get the X. Fail more than one, you'll get no connectivity with wifi and the phone will revert to 3G/4G.

    I just disabled it in all of my phones. Only catch? When you're connected to a real foreign hotspot (hotels, starbucks, whatever) the automatic portal authentication will not start. You will have to use the browser to be redirected to the authenticator portal.

    End of story? Try to sniff on the traffic the android os will make to check for connectivity and make sure in scenario1 that none of your other wifi equipment is interfering with it. In scenario2, I presume, no traffic whatsoever is routed until authenticated so the phone has no doubt in its algorithm that it must authenticate first. Scenario3, if I'm right with 2, is like back to scenario1, since the Captive Portal will allow traffic, but the probe could fail for other issues....

    Have fun with debugging

  3. #3
    Untanglit TheDude's Avatar
    Join Date
    Dec 2017
    Location
    Missouri
    Posts
    17

    Default

    Thanks for your input man! I was thinking along the same lines of the round robin issue. It is pretty much what it has to be. I will do some sniffing, I think I will also look at aosp source and try to figure out what exactly android is doing. My hunch is that this is tied to 1e100.net dns resolution. I can exclude that domain but it always resolves to a different IP. When I exclude that IP it just jumps to a different one in the pool, None of which have a valid certificate installed which would explain the abandoned errors. Real pain in the A$$ this has been so far :/ I guess I could try redirecting 1e100.net dns to a known connectivitycheck server that has a valid cert...? I will try a few things and report back. Thanks again for your input! I am glad to know I am not the only one in this boat.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

SEO by vBSEO 3.6.0 PL2