XPost: alt.comp.os.windows-10, comp.mobile.android, misc.phone.mobile.iphone   
   From: marianjones@helpfulpeople.com   
      
   Marian wrote:   
   > Hence, an active scanner, if it "waits long enough" and if it captures   
   > authentication traffic, can capture these frames and learn the SSID but   
   > only if a client connects, as if no client connects, a passive scanner will   
   > only know the BSSID, not the SSID of the router's access point.   
      
   It's nearly impossible to find the official iOS/Android stance on whether   
   the BSSID of a hidden access point is "collected" or "uploaded" to   
   Apple/Google servers, but we can look at when the SSID is sent in the   
   clear.   
      
   1. For an average dumbshit user, he has his router set to defaults,   
      so the SSID is sent in cleartext in the beacon frames from the AP.   
      This happens "periodically" (perhaps every 100ms or so).   
      However, if the SSID is hidden, the beacon SSID field is blank.   
      
   2. If a random scanner passes by, it often sends wildcard probe requests.   
      The access points set up by dumbshits respond with a probe response   
      that includes their SSID in cleartext but not if the SSID is hidden.   
      
   3. An access point set up to be hidden will never include the SSID in the   
      probe response, and, depending on the firmware, it will either stay   
      silent or it will reply with a probe response with a blank SSID field.   
      
   4. The only way an AP reveals the SSID in the clear is if the client sends   
      a directed probe request (with the SSID filled in) because then the AP   
      will respond with a probe response that includes the SSID in the clear.   
      
   If no client ever sends out a directed probe request, then the SSID will   
   never be found in any packet that can be sniffed by any nearby scanner.   
      
   What happens in the case of a hidden SSID with auto-reconnect turned off is   
   a. ONLY when you physically manually initiate a connection to a hidden SSID   
   b. The client sends a directed probe request containing the hidden SSID.   
   c. The access point repeats the hidden SSID in the directed probe response   
   d. The client sends an association request containing the hidden SSID   
   e. The AP sends an association response containing the hidden SSID   
   f. Encrypted authentication handshakes & encrypted traffic follow   
      
   While the BSSID remains visible in all subsequent frames, the SSID is no   
   longer exposed in later frames, whether or not the AP SSID is hidden.   
      
   The only time re-association could occur is if you manually disconnect from   
   one AP and then manually connect to another AP with the same hidden SSID.   
      
   If a random iOS/Android phone is sitting outside your house, and if your   
   phone manually connects during that hour to the hidden SSID access point,   
   the random phone outside can see the hidden SSID in cleartext. It will   
   appear in the probe request, probe response, association request, and   
   association response frames. After the connection is established, the SSID   
   disappears from later traffic, but by then the random phone has already   
   captured it.   
      
   But wait, there's more.   
      
   Wi-Fi frames are only visible to a sniffer if it is tuned to the same RF   
   channel as the AP at the moment those frames are exchanged. And that   
   exchange typically takes only about a second to complete. So the window in   
   which the hidden SSID is in the clear is extremely short, especially for   
   the 5GHz range since there are more channels the sniffer has to scan.   
      
   The probability of capture depends on channel scanning behavior where a   
   random phone scanning all channels may miss it, but a dedicated sniffer   
   locked to the AP's channel will always catch it instantly.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)