The hunt for the hidden probe

Analysis

I recently discussed with a co-worker about hidden SSIDs.

Now we all know - as it is pretty much common knowledge and covered in even the basic wireless-, networking-, and security training - that hiding the SSID provides no security gain at all. Not only that; it has adverse effects, with certain clients not joining and roaming problems.

But the question that arose: Does a hidden SSID generate a probe response to a wildcard probe (“null”) request?

As it turns out, the answer is not that easy to find.

Now don’t get me wrong, it is clear that the SSID string would not be in such a response, as this would render hiding an SSID even more useless than it already is. But as a probe response is essentially a beacon frame - with a few subtle differences - it would not be too far-fetched to expect a probe response in my opinion. It would not tell you more than the beacon with the “null” SSID, so there is not really a downside, other than having to send one frame more (and expecting an acknowledgment back).

But trying to look up an answer to this did not yield much results. Looking through both CWAP books I have access to, the CWSP book, the CWNA book, and looking this topic up on the internet did not get me a concise answer.

I did get a few little bits though:

(CWAP PW0-205 2004)
Some access points allow administrators to disable the broadcasting of the SSID in beacon frames. Additionally, these same access points often have functionality allowing the administrator to control whether the access point responds to probe request frames that have null (broadcast) SSID fields.

We do know that “hiding” (disable broadcast) of the SSID is possible. That it is possible on some APs to enable not answering wildcard probe requests at all is a different thing, but does not answer if a “hidden” SSID would generate a probe response on a wildcard probe request (when enabled).

(CWSP-206 2019)
SSID hiding is a technique implemented by WLAN device manufacturers that will remove the information found in the SSID information element from Beacon management frames. Depending on the implementation, SSID hiding may also remove it from Probe Response frames sent from the AP.

Now we are getting somewhere. Do note that this does not specify that we are talking about probe responses as answers to wildcard probe requests, but I think it is safe to assume here, as not responding to probes at all would render the SSID useless.

“Depending on implementation” is the keyword here - there is not a clear cut answer. Why is that? Because hiding the SSID violates the standard. There is nothing in the 802.11 standard about hiding the SSID - this was just a reaction of vendors to the WEP debacle.

The standard is pretty clear on probe responses:

(IEEE Std. 802.11-2020)
11.1.4.3.4 Criteria for sending a response
…
A STA that receives a Probe Request frame shall not respond if any of the following apply:
…
g) The STA is not a mesh STA and none of the following criteria are met:

  1. The SSID in the Probe Request frame is the wildcard SSID.
    …

Now the wording here is a bit tricky with double and triple negatives. But the STA should send a probe response, except in a few cases. A normal AP getting a wildcard probe request is not one of them, so it should respond.

Hiding the SSID violates the 802.11 standard, so whatever AP manufacturers implement to probe requests then is up to them. This also explains some stray answers that I found with Google that the AP “may” or “may not” send a response.

So, to no longer assume, I decided to make a small test bed and just try it out. I gathered APs of different vendors and software from my lab that I currently have a license for, and this was the result:

My small testbed

  • Cisco C9105AXI running with C9800-CL Controller 17.9.3
  • Mikrotik mAP lite running RouterOS v6.47.10
  • Ubiquiti UniFi6 Enterprise running 6.5.62
  • Cisco CW9166I running with Meraki MR 30.5

I configured the SSIDs the same on all APs - 3 SSIDs, named “Now you”, “See me”, and “Now you don’t”. The third one would be the “hidden” one. I chose two visible SSIDs, to see at least two probe responses.

As an example, how the config looked in Meraki:

3 SSIDs

Third SSID hidden

I checked that the SSIDs were broadcasting (or not) as expected using WiFi Explorer Pro, here as an example the Mikrotik AP:

Mikrotik AP in WiFi Explorer Pro - as expected, 2 visible and one hidden SSID

Now, with my testbed configured, I can go on and try. This means in this case to just capture frames of Probe Requests and Probe Responses. I captured it on my MacBook using AirTool and triggered Probe Requests with my iPhone, just opening the Wi-Fi settings.

I did cut out irrelevant stuff to just leave one set of beacons before and after the probes.

These are my results:

Cisco on 9800 Controller

Cisco on 9800 packet capture

We can see clearly that the “hidden” SSID gets its own beacon frame, leaving the SSID name blank (wildcard) in frame 3. Frame 4 is the wildcard Probe Request from my iPhone, which is followed by 2 (two) Probe Responses for the “visible” SSIDs, and acknowledged by my iPhone. After that, the AP returns to beaconing.

So Cisco APs on 9800 Controllers do not send responses for hidden SSIDs on wildcard probes.

Mikrotik

Mikrotik packet capture

This looks essentially the same as the Cisco AP. The only funny difference is that the responses are the other way around than in the beacons.

So Mikrotik APs also do not send responses for hidden SSIDs on wildcard probe requests.

Ubiquiti

Ubiquiti packet capture

We do have some differences with UniFi, as there is a second hidden SSID here. This has not been configured and is just part of Ubiquitis meshing and we can ignore it. Other than that, this is just more of the same - the hidden SSID gets a beacon, but not a probe response.

Meraki

Meraki packet capture

This actually looks more like the Ubiquiti capture than the Cisco capture, as Meraki also uses a hidden SSID for their meshing. But to answer the original question: Meraki does it as the other candidates and does not send probe responses for hidden SSIDs as an answer to wildcard probe requests.

Mist

Mist packet capture

Thanks to Karsten Iwen, I got a capture using my SSID examples from a Juniper Mist AP (SW Version 0.12.27139).

What stands out here is that the beacon of the hidden SSID is zeroed out - Mist seems to set UTF Nulls on hidden SSIDs, which seems to work - it is displayed as “hidden” in Wi-Fi Explorer. But the outcome to our question remains the same - no probe response for the hidden SSID.

Conclusion

So using the hardware (and licenses) that I had in my lab, I could not see the probe response I was looking for. Given the different manufacturers, I would be surprised if one of the major vendors would do it, but I would be happy to hear your experience with Aruba for example.

While the correct answer to the original question “Does a hidden SSID generate a probe response to a wildcard probe (‘null’) request?” would be the classic “It depends!”, it seems that “probably not” does seem to be a more valid answer.