When working with various customers on their wireless networks, I am often asked about the broadcasting of Service Set Identifiers (SSIDs) – or the name of the Wi-Fi network – as a security risk. At one time, broadcasting of SSIDs was seen as a security issue, and therefore almost everyone disabled broadcasting. Since that time, we have grown as an industry in our understanding of this practice to the point where it is generally considered best practice to broadcast SSIDs. As an example, PCI DSS v1.2 removed the requirement for SSIDs to be non-broadcast in order to be PCI compliant.
I do want to begin by noting that there are a couple of valid reasons TO NOT broadcast SSIDs:
- There are certain clients – generally older ones with out-of-date drivers – that can hang when seeing more than five SSIDs being broadcast. I very rarely see this issue.
- If you are using an open SSID without any type of authentication, either layer 2 or layer 3, that should generally not be broadcast. It presents a risk in terms of the number of unwanted devices connecting through the network. Of course, a completely open SSID should be avoided if at all possible, whether or not the SSID is being broadcast.
Now, there are many more valid reasons to broadcast SSIDs:
- If an SSID is not being broadcast, then the Windows wireless supplicant requires that the box “Connect even if the network is not broadcasting its name (SSID)” be checked. In turn, that causes the Windows laptop to send out probe requests with the SSID name wherever they are located, even if it is not within range of the SSID. This, in essence, broadens the locations where the SSID can be seen – rather than diminishing them, as intended.
- The 802.11i-2004 standard, on which WPA2 is built, states an “STA may decline to communicate with STAs that fail to advertise an RSN information element in their Beacon and Probe Response frames or that do not advertise an authorized SSID" (p. 66, under "8.4.2 RSNA selection”). This means that a client desiring to connect to a WPA2 enabled SSID is not required to connect to one that is not broadcasting its SSID.
- Some clients, notably Windows XP machines, will join a broadcasted open SSID (open from an OSI Layer 2 perspective) instead of their specified secure SSID if that secure SSID is not being broadcast. In fact, Microsoft specifically states that SSIDs should be broadcast in order for Windows XP machines (and Vista to a lesser degree) to operate properly.
- Some clients, notably Apple products, have historically had issues with joining a non-broadcast SSID, particularly in the presence of another broadcast SSID.
- Setting up of clients, if not pushing out policies via a central management utility, is more difficult when not broadcasting SSIDs.
- Troubleshooting tools often rely on the SSID being broadcast in the beacon.
- Some clients roam more quickly when seeing the SSID in the beacon, making for less drops in connectivity.
As a general rule of thumb, SSIDs should be broadcast – and deciding against broadcasting SSIDs does not actually increase security, as the above reasons show.
Want to improve your wireless environment?
Register for a free wireless performance and management assessment of your environment, and learn how to:
-
Ensure that the wireless network is providing the most business value
-
Build a wireless network that can support growing user, device, and application requirements
-
Significantly reduce time to issue resolution
-
Simplify network operations
Topics: Enterprise Networking, Wireless
