Non-Broadcast Wireless SSIDs Why hidden wireless networks are a bad idea

http://blogs.technet.com/b/networking/archive/2008/02/08/non-broadcast-wireless-ssids-why-hidden-wireless-networks-are-a-bad-idea.aspx
In Microsoft CTS Network support, we frequently need to troubleshoot wireless connectivity issues. These issues are always made more difficult to resolve in instances where the wireless network is hidden. We recommend that customers do not use non-broadcast or hidden SSIDs. It is a bad idea from both functionality and security standpoints.

What is a hidden wireless network?

It is possible to configure most wireless Access Points (AP) to not broadcast their SSID (Service Set Identifier). The intent of this feature is to prevent unauthorized users from being able to detect the wireless network from their wireless clients. APs send beacon frames to advertise capability information and parameter sets for the network. Turning off broadcasting on the AP does not prevent the beacon frame from being sent. The wireless AP still sends a beacon frame, but it is sent with the SSID value set to NULL.

An Analogy

Let's say I am planning a party, and I invite several friends from work. I tell them to meet me at my street address on Friday night. I will be grilling steaks and burgers out in the back yard, and they should just bring their favorite beer. Many of them plan to meet me at the designated time, and they let me know that they will arrive carrying various containers of beer.

On the night of the party I get a little nervous, because I just bought a whole bunch of steak and burgers. I live in a pretty sketchy neighborhood, and I don't want just anyone to walk in and eat the food, particularly if they haven't brought any beer to share. So I decide to implement a security measure.

Well, I guess I could lock the front door and wait until people arrived and rang the doorbell. Then I could look out the window and verify that the caller is an invited guest. I could speak with them and verify that they are who they say they are in the same way that Active Directory verifies users with MS-CHAPv2. I suppose I could issue written invitations to the guests and require that they present the invitation to a third party prior to even allowing them to ring the doorbell like with a PKI deployment. But I have another idea.

In the interest of security, I go out and tear the numbers off the front of my house and off the side of my mailbox. I go to the corner and uproot the street sign. Now nobody looking to crash the party can find my house because it has no identifier!

Well the guys from work arrive, some of them in my general neighborhood, but none of them can find my house because the identifying street name and number are missing. They have two choices now - either they can give up and forget about the party or start asking around for where my house is. Most of them roam about the area carrying beer and yelling out my address.

So let's say the local hoodlums are out, and they want to score some beer and steak. I didn't invite them to my house, but they can still see that it is a house. They can still smell the steak and burgers cooking, and now they can hear and see a bunch of guys carrying beers, yelling out my address and roaming aimlessly in search of the party. The party crashers can easily surmise what my address is in the unlikely event that this is of any interest to them.

This was a poor choice for a security measure.

Choosing not to broadcast the SSID of a wireless network does not make it undetectable. The SSID is still advertised in the probe requests sent out by wireless clients and in the responses to the probe requests sent by wireless APs.

If you manage a wireless Access Point and the network it connects to, you control the security associated with accessing it. You specify encryption methods such as AES or TKIP and authentication requirements such as PEAP-MS-CHAPv2, EAP-TLS or PEAP-TLS in order to secure the network. You can require a valid username and password, or require that clients present a certificate to a PKI (Public Key Infrastructure). The name of the network itself is only an identifier and is not a security element. In fact the name of the network has no bearing on security whatsoever from an encryption or authentication standpoint.

If the network name of a wireless network (SSID) is not broadcast, the clients must search for it with probe requests. So if you have one AP and 100 wireless devices, you partially limit exposure of the network name with one device while causing 100 devices to expose it instead. The probe frames sent by the clients advertise the SSID every 60 seconds, whether they are close to the actual AP or not. This means that instead of one device broadcasting the SSID in the immediate proximity of your network, you now have these 100 devices potentially advertising the SSID in every coffee shop, hotel, and airport they visit. The security vulnerability this exposes is worse the larger the wireless deployment is.

How does Windows XP deal with non-broadcast SSIDs?

In Windows XP or Server 2003, users can connect to non-broadcast networks by configuring a preferred wireless network either manually or through Group Policy. A non-broadcast network will not appear in the "Choose a wireless network" dialog box.

The wireless supplicant will look at all the available networks and try to match them up to the networks in its preferred list. If it finds a match set to automatic connection, a connection attempt will be made. If no match is found after comparing visible networks to the preferred list, it will start plumbing down each network in the preferred list from top to bottom. It will wait two seconds to see if a connection is made, then proceed to plumb down the next one in the list.

This process will allow the supplicant to connect to a hidden network if it is in range, but only if no other preferred networks are available and visible. Because of this, even if a non-broadcast network is at the top of the preferred list, it won't take priority over a broadcast network lower in the list.

In order to address this problem, you can apply Windows Server 2003 SP2 or the wireless update from KB article 917021 to Windows XP SP2 machines. This allows you to configure wireless networks as broadcast or as non-broadcast networks. You can also configure this new setting through Group Policy from a computer that is running Windows Vista. If a non-broadcast network is configured as preferred, the XP client will now probe for it every 60 seconds, in effect broadcasting the SSID of the network.

How does Windows Vista deal with non-broadcast SSIDs?

In Windows Vista and Server 2008, there is an additional configuration setting to specify whether a network is non-broadcast. Within the Wireless Network properties dialog, there is now a check box for "Connect even if the network is not broadcasting." This causes the supplicant to send probe requests for the network, and if it is in range it will be displayed in the list of available wireless networks.

These probe packets still occur every 60 seconds, regardless of whether the network is reachable, and this constitutes a security risk by probing for the SSID repeatedly. A malicious user could attract the client to an unauthorized AP simply by duplicating the SSID and settings learned from the probe packets.

Also, if a Windows Vista or Server 2008 client receives a beacon frame with the SSID set to NULL, it will add the network to the list of available networks with the name "Unnamed Network". This allows the user to manually connect to the network if it knows the correct SSID.

How It Breaks

The ability to connect to a non-broadcast SSID is a cooperative effort between the wireless supplicant and the wireless NIC driver. In order to take advantage of the improvements made to the supplicant in Vista, the wireless adapter driver must support these enhancements.

In order for the new process to work, the wireless driver must send the probe packet to the AP for the hidden SSID. We have seen that power settings defined on the NIC driver can influence whether the AP receives this probe. Sometimes setting the transmit power setting to maximum will allow the probes to reach the AP.

Currently there are several widely-distributed WLAN drivers which either do not support or do not work properly with the Vista method of dealing with non-broadcast SSIDs, including the Intel 3945ABG and the Broadcom 802.11g Network Adapters.

The Intel 3945ABG adapter is very widely distributed in current laptop models. The latest Intel driver provides improvement but does not address all issues with hidden SSIDs encountered when roaming or resuming from hibernation.

Broadcom does not show any unnamed networks, and they are not planning to fix this. One of the reasons, besides being low priority for them, is also to push customers to stop hiding the SSID, which creates a problem instead of solving it.

Windows Vista includes a warning to indicate that connecting to a hidden SSID is a bad idea from a security standpoint:



Non-broadcast SSIDs are not a valid security measure and actually make it easier for the SSID to be discovered since it forces clients to continuously probe for it.

Here is our official stance from Microsoft on Hidden SSIDs:

— From Wireless Product Manager Drew Baron: "We like to take every opportunity to dissuade the use of Hidden SSIDs as much as possible. For security reasons we strongly recommend against using hidden SSIDs" http://www.microsoft.com/technet/network/wifi/hiddennet.mspx

— Here is a link to an independent analysis from outside Microsoft: "Debunking the Myth of SSID Hiding" - http://www.icsalabs.com/icsa/docs/html/communities/WLAN/wp_ssid_hiding.pdf

— Input from Senior Security Strategist Steve Riley:
"It's a violation of the 802.11 specification to keep your SSID hidden; the 802.11i specification amendment ... even states that a computer can refuse to communicate with an access point that doesn't broadcast its SSID."
http://blogs.technet.com/steriley/archive/2007/10/16/myth-vs-reality-wireless-ssids.aspx