TISC Insight, Volume 4, Issue 16

Welcome to Volume 4, Issue 16 of The Internet Security Conference Newsletter, Insight. Insight provides commentaries and educational columns, authored by some of the best minds in the security community.

TISC is about sharing clue. So is this newsletter. We promise to provide something useful each issue. If we don't, flame me. If you like the issue, let us know!

Enjoy, and be safe,


Editor's Corner

Security through Obscurity. If you can't see me, or find me, or recognize me for what I am, you probably can't attack me.

General opinion is that relying *entirely* on obscurity is A Bad Idea. But smoke screens, bluffs, and misdirection have been and remain useful defensive strategies.

WiFi LANs have had to weather constant pounding and criticism about the shortcomings in 802.11 WLAN security. Scrambling to stem the anxiety over deploying WLANs in enterprises, vendors recommend "obscuring" Service Set Identifiers to remove your WLAN from the low hanging fruit. By setting your SSID to some value other than a default, you can eliminate accidental associations.

Turning off SSID broadcasts is another commonly-recommended practice. The (false) premise here is that SSID broadcasts increase the exposure of SSIDs over RF. Specifically, someone has to actively hunt for your AP instead of (pardon the pun) stumbling upon it.

In today's column, Bob Moskowitz explains that this premise is categorically incorrect, and illustrates a fairly broad misunderstanding of the protocol operation consequences on the part of those who mistakenly assume they raise the security bar by eliminating WLAN SSID broadcasts.

Happy reading...

The Myth Of Hiding SSIDs

Robert Moskowitz, ICSAlabs

In 802.11, the SSID, or service set identifier, is used to identify all of the components of an 802.11 network, or ESS (Extended Service Set). Many security professionals recommend that hiding SSIDs is a security measure. I will show that SSIDs cannot be hidden under normal WLAN operation, and attempting to hide SSIDs negatively impacts WLAN performance.


SSIDs function in 802.11 much as NetBios Scope functions in Microsoft networking: to logically segment the network. SSIDs are 0 to 32 bytes long. A zero byte length SSID is called the Broadcast SSID. SSIDs occur in the following frames:

The method that 802.11 vendors use to hide the WLAN's SSID is to use the Broadcast SSID in the BEACONs. For the STA to join or roam in a WLAN, the STA sends an ASSOCIATE or REASSOCIATE Request to the AP. The ASSOCIATE and REASSOCIATE frames always contain the WLAN SSID. If they were to use the Broadcast SSID there would be no restrictions to which STAs can join the WLAN. If the SSID in these frames do not match the SSID configured in the AP, the AP rejects the association. There is no Reason Code in 802.11 for 'Invalid SSID'; thus the most likely reason code will be 'Unspecified reason'.

A Broadcast SSID can be used in any of these frames. However, it is difficult to operate a WLAN if PROBE Responses contain the Broadcast SSID. Thus, practically speaking, only the BEACONs and PROBE Requests can use the Broadcast SSID, meaning the WLAN's SSID is regularly exposed.

The Normal WLAN Operation

The normal operation of a WLAN is for all the APs to transmit BEACONs at 5 to 20 times per second with the WLAN's SSID, along with the time, capabilities, supported rates, and PHY parameter sets. STAs configured for that SSID would then measure the signal strength of each AP and select the best AP for Association. This is called passive scanning. The STA sends an ASSOCIATION Request with the SSID to start its connection with the AP.

If the STA roams from one AP to another, it may use a REASSOCIATION Request with the SSID, but most STAs actually send an ASSOCIATION Request even when roaming. BEACONs permit a STA to easily find the strongest signal for the WLAN and minimizing bandwidth consumption for WLAN management.

This behavior pattern allows for efficient operation of the WLAN, particularly in the presence of other WLANs at the cost of announcing the name (SSID) of the WLAN.

The 'Hidden' WLAN Operation

Some APs provide a switch to exclude the SSID from the BEACON. BEACONs are still sent, providing the timing, channel, data rates, and other capabilities. This is done to 'hide' the WLAN's identity, its SSID. When this is done, the STA cannot directly discover its WLAN and MUST be configured with the SSID. In actuality, the AP is using the Broadcast SSID in the BEACON, and this forces the STAs to use active scanning to find their WLAN (since the STA does not passively detect any AP BEACONs with its SSID).

For a STA to join a WLAN, it sends PROBE Requests on all channels with its SSID, and listens for PROBE Responses, also with SSIDs. The STA uses all PROBE Responses, as it would BEACONs, to select the strongest signal for the WLAN. Normal ASSOCIATION Requests are then used to join the WLAN. Since the ASSOCIATION contains the SSID and if the SSID is wrong for the AP, resulting in an ASSOCIATION error, the SSID has become to be viewed as a password. This is quite mistaken; they are community labels that any device can assert to claim membership in a WLAN community.

From this it would appear that WLANs can be effectively hidden as PROBEs, ASSOCIATIONs, and REASSOCIATIONs that carry the SSID should be infrequent and missed by a war driver. However, there are two conditions that actually make SSIDs appear more frequently in a WLAN than when BEACONs do carry the Broadcast SSID.

For a STA to roam, it needs to discover an AP with the strongest signal. Roaming is not just for a STA that is physically moving. Any STA that has a 'weak' signal (for some vendor definition of weak) will attempt to roam. A STA can be forced to roam when the environment around it changes, for example when additional STAs start up, or interference starts (hand on PCMCIA wireless card or microwave in breakroom started). A STA preparing to roam in a WLAN whose BEACONs do not carry the WLAN SSID, but rather the Broadcast SSID has to actively scan for APs. The STA sends out PROBE Requests sequentially on all channels with its SSID and listens for PROBE Responses. The STA may do this channel scanning every 50 msec as it attempts to discover a stronger signal. In some office configurations, STAs have been observed to 'bounce' between APs, spending only minutes on one AP and then switching to another based on signal strength. Thus a WLAN that has STAs with weak signals from the APs will readily expose the SSID in all the PROBE Responses and ASSOCIATION frames.

The excessive PROBE Requests and Responses in this configuration have the potential to negatively impact on WLAN performance. Particularly when there are many STAs roaming. And again, roaming does NOT require the STA to physically move. A STA with a weak signal (including one whose reception is weakened due to local interference) or located between two APs attempts to roam.

Further Impacts of 'Hiding' WLANs

When a STA sends a PROBE Request, ALL APs that receive it MUST send a PROBE Response with the SSID even if the PROBE Request contains the Broadcast SSID. Some APs have a switch to disallow this standard behavior. That is, they will only send a PROBE Response if the Request had a matching SSID. This switch is typically a different switch from the BEACON SSID disable switch, and is rarely set even if the BEACON is set to 'hide' the SSID. Attackers can readily use this to discover the SSID of a 'hidden' AP that will respond in the standard way.

Additionally, there is a relatively simple method for an attacker to learn the SSID of a 'hidden', but active, WLAN. The attacker sends a spoofed DISASSOCIATE message for an active STA to the STA's AP (there are tools for this). This will force the STA to rejoin the WLAN. The STA will first cycle through PROBEs and then ASSOCIATE. This will occur within a second after the DISASSOCIATE attack. This method to force a hidden WLAN to reveal its SSID could take less than second when launched against a STA actively transmitting data.

Finally, Ad Hoc WLANs work the same as Infrastructure WLANs, with the following caveat. All STAs can send BEACONs and/or PROBEs. So the same mechanisms exist to find the SSID of Ad Hoc WLANs as in Infrastructure WLANs.

As with Infrastructure WLANs, excessive PROBE Requests and Responses will negatively impact performance. Of course since Broadcast messages are sent out as unicast messages to all STAs in an Ad Hoc WLANs (as compared to sent twice in Infrastructure WLANs), Ad Hoc WLANs typically always suffer from poor performance.


The SSID of a WLAN is readily exposed in the normal operation of MOST WLANs, even when the APs are configured to 'hide' the SSID. It is the actions of the STAs that exposes the SSID. When SSIDs are 'hidden', there is additional WLAN management traffic that adversely effects the WLAN's and a roaming STA's performance. SSIDs are not passwords; they are community labels that any device can assert to claim membership in a WLAN community.

Attempts to hide the SSID are a false sense of security, and should not be pushed by the security professional. This practice adds to the workload of the already over-worked security and network administrators, while not returning any real benefit for their labors.

About the Author

Robert Moskowitz is Senior Technical Director at ICSAlabs and a contributing editor to Network Computing Magazine. He works with security protocols including having co-chaired the IPsec workgroup in the IETF and created the concept of the Bridge CA for the US Fedreral PKI.. He is currently working on wireless security, having developed the security model for IEEE 802.11f (Inter-Access Point Protocol) and participates in IEEE 802.11i, IEEE 802.1aa, and IETF EAP security work. He also works with Digital Identity issues and can be reached at rgm@icsalabs.com, rgm@trusecure.com, rmoskowitz@cmp.com, or rgm@htt-consult.com.

Like what you read? Subscribe!
Suggest a topic for a future Insight.

© 2002 Robert Moskowitz
Published by Core Competence & Mactivity, Inc.
with permission of the author.