Monday, March 12, 2012

Android hidden AP weirdness

@jduck1337 brought this to my attention:

It was too long-form to continue the discussion on Twitter, so here we go:

The bug is, basically, that when looking for a hidden AP, Android doesn't care what the BSSID of the response is, ie, it doesn't cache the BSSID of known hidden SSID APs.

This actually doesn't seem, to me, like a bug at all.  The BSSID is not relevant to association, the SSID defines the network.  On a multi-AP roaming network any number of BSSIDs could reply to a probe request for a hidden network.

The assumption that being able to reply as the hidden network leads to loss of credentials doesn't make any sense either:  Sure, the client will try to talk to you to do a WPA handshake, but if you don't know the key, it won't succeed, and it trying to associate won't give you insight into the key.  Also this doesn't give you anything that setting up a generic rogue wouldn't give you.

So unless there's something I don't understand going on, I don't see the threat.  I don't even see the bug - when you send out a probe to see who is out there, you have to expect any number of responses, and the whole mechanism of roaming is to go to a new BSSID.  From the bugtraq post:

5. Turn off the first AP
6. Turn on the other AP
7. See your Android device automatically connect to the second AP
This is exactly how roaming is SUPPOSED to work, this 
doesn't seem like a bug to me.
Anyone see something I don't? 


  1. Yeah, that seems like normal roaming behavior to me. Though the author says iOS won't do the same thing, which seems kind of odd as well.

  2. Hidden SSIDs are kind of a fundamentally broken model anyhow since dot11 really wasn't meant to work that way. Still, this is the only way a multi-ap network can handle roaming, hidden or not.

    I'm not sure how IOS would do it differently other than "not work" if you had more than one AP w/ the same hidden SSID.

  3. Seems normal to me as well. I've set up a hidden SSID WPA2 AP just to see if iOS would connect automatically, and it does (both 5.0.1 and 5.1). If I set up a different AP at a different location with the same settings, it reconnects to the other AP just fine.

  4. This is indeed regarded as 'normal' WiFi roaming, and only if it would work while NOT shutting down one AP to make the Android device actually switch over the the 'better' AP, I would not have an issue at all.
    If this would not be 'normal' it would require every device to actually manually authenticated with all [hidden] BSSID's in your network before roaming would work. Possible in a small shop environment, but not really in a >100 AP cloud with >2000 devices.
    The major problem of Android on many devices, is the inability to actually aggressively switch over from one BSSID an other BSSID [with far superior signal strength] within the same SSID. Something that Windows & iOS have mastered years ago. Google flags the issue as Declined, so this problem is here to stay.

  5. yeah, android sucks at roaming. In general, '*' sucks at roaming.