Monday, November 29, 2010

CAPWAP AP Join Process

Once the LWAPP/CAPWAP access point has discovered and selected a controller, the next step in the process is for the AP to join the selected controller. The join process verifies the identity of both the Cisco access point and controller, ensuring that only valid Cisco APs with either a Manufacturer Installed Certificate (MIC) or Self-Signed Certificate (SSC) from an autonomous AP conversion to lightweight mode can join the controller. This process also establishes a secure communication path for the LWAPP/CAPWAP control channel to ensure that only the current controller can configure and manage the access point.

The LWAPP and CAPWAP protocol join process is built on existing asymmetric and symmetric cryptography, hashing, and digital signatures. For an introduction to these concepts, see Public Key Cryptography, SSL and TLS protocols.


To join the controller, the access point and controller perform the following process:
1.      AP sends Join Request
a.       Random Session ID
b.      X.509 Certificate of LWAPP
2.      Controller Verification
a.       Verifies LWAPP X.509 Certificate was signed by a trusted CA
b.      Generates random AES encryption key for LWAPP Control traffic
c.       Encrypts AES key using LWAPP Public Key
d.      Concatenates key ciphertext with the Session ID from LWAPP Join Request
e.       Encrypts concatenated string with Controller’s Private Key
3.      Controller sends Join Response
a.       Ciphertext (Session ID, encrypted AES key)
b.      Controller’s X.509 Certificate
4.      LWAPP Verification
a.       Verifies Controller X.509 Certificate was signed by a trusted CA
b.      Decrypts concatenated string using Controller’s Public Key
c.       Validates the Session ID
d.      Decrypts the AES key using LWAPP’s Private Key
5.      Join Process is now completed
6.      AES Key Lifetime timer is 8 hours
a.       LWAPP sends LWAPP Key Update Request (contains new Session ID)
b.      Controller generates new AES key and encrypts as stated above.
c.       Controller sends LWAPP Key Update Response


All LWAPPs manufactured after July 18, 2005 have Manufacturer Installed Certificates (MIC) burned into protected flash memory. Upgraded access points manufactured prior to this date will have Self-Signed Certificates (SSC) installed during the upgrade process. The Cisco Upgrade Tool must be used during the upgrade of older APs in order to generate the self-signed certificate. SSCs are not trusted by default by the WLCs, so a mapping of AP MAC addresses to SSC Public Key hashes is created at the time of upgrade by the Cisco Upgrade Tool. This list can then be imported into WCS and pushed to the WLC.


Access points can also be restricted from joining a controller based on the AP Policies settings in the Security tab of the WLC. This allows more granular control of APs allowed to join a controller if the organization does not want to allow any valid Cisco AP to join for security reasons. 


Select the type(s) of certificates to accept (SSC, MIC, LSC) when authorizing APs against the AP authorization list. SSC certificates always require valid AP entries in the AP authorization list. MIC and LSC are accepted by default, and will only be checked against the AP authorization list if their respective authorization check boxes are enabled.




Debugging the LWAPP Discovery and Join processes can be accomplished with the following commands:

LWAPP Console Port Commands
debug ip udp
debug lwapp client events
show crypto ca certificates

WLC Commands:
debug lwapp events enable
debug lwapp packet enable
debug lwapp error enable
debug pm pki enable
show time

It is VERY important that the WLC have the correct time set, otherwise it may reject the LWAPP Certificate during the Join process because it is outside the validity interval. To set the correct time on the controller, issue the config time CLI command.

If LWAPs are using Self-Signed Certificates, ensure that the WLC is configured to accept the SSCs:
show auth-list
config auth-list ap-policy ssc { enable | disable }
config auth-list add { mic | ssc } ap-mac ap-keyhash
config auth-list delete ap-mac



Cheers,
Andrew

CAPWAP Controller Selection Process

Once a CAPWAP access point has discovered and built a list of all one or more available wireless LAN controllers, it is ready to select the optimal controller to join.

Controller selection is based on the following information embedded in the Discovery Response from each candidate controller:
1.      Controller sysName
2.      Controller Type
3.      AP Capacity
4.      Current AP Load
5.      Master Controller Status
6.      AP-Manager IP Address(es)
7.      Current AP Load on each AP-Manager IP Address

The AP will select a controller based on the following precedence rules:
1.      Primary configured controller preference
2.      Secondary configured controller preference
3.      Tertiary configured controller preference
4.      Primary Backup controller (WLC version 5.0 and later)
5.      Secondary Backup controller (WLC version 5.0 and later)
6.      Master Controller status of WLC
7.      Controller with greatest excess capacity
a.       Ratio of current AP load versus maximum capacity; expressed as a percentage

Note – Once an access point joins a controller, it learns the information of all controllers within the Mobility Group and stores their IP addresses in NVRAM. The AP may join another controller with greater excess capacity if no controller preferences are configured.

Cheers,
Andrew

Friday, November 26, 2010

CyberMonday Wish List

Inspired by Dan's post on his cyber Monday wish list over at Margin Scribbles, here is my own wish list for this holiday season.

  1. CACE Wi-Fi Pilot and 3-Pack AirPcap Nx Adapter - sniffing packets is just so much fun, what better way to celebrate the holidays. I've always been hamstrung capturing wireless frames in monitor mode on my Windows PCs, having to resort to loading up a Linux distro (may I recommend Backtrack v4 just released). So this year I would like native Windows capturing capabilities to increase my wireless efficiencies. I could use Omnipeek as well, but I'm more familiar with Wireshark and Omnipeek workstation licensing is so unfriendly.

  2. Arkon IPM127 bicycle mount for iPhone - riding my bicycle spring through fall in Minneapolis is great. Carrying my GPS integrated iPhone in the back of my jersey or in a seat-pouch is not. I need to be able to view my progress while I'm riding, pause tracking while waiting for those infrequent intersection cross-walks which I avoid as often as I can, and keep my butt motivated to perform better than the last time. Combining a bicycle mount, music player, and a GPS bicycle tracking app such as Cyclemeter.

  3. Star Trek TNG Complete DVD Series - okay, strictly speaking this is not a techie item. But I love Star Trek The Next Generation and have been recording re-runs on my DVR for a year now. That's just not cutting it anymore, I must own the complete series. Someday, my future kids will watch Picard save Earth from the Borg, I know it.

  4. Immunity SILICA-U - penetration testing can be so much fun. I've played with tons of pen-test tools, my favorites being BackTrack, Metasploit, aircrack-ng, and coWPAtty. But if I'm going to get serious about this stuff I need a professional wireless pen-testing tool. Immunity's SILICA-U takes wireless pen-testing to the next level, and I want some of that action.

I have plenty more geeky toys in my wish list, but those are my tops.

Cheers,
Andrew

Tuesday, November 23, 2010

CAPWAP Controller Discovery Process

In a controller-based architecture, CAPWAP access points are dependent on a wireless controller to provide the software image, configuration, and centralized control and optionally data forwarding functions. Therefore, it is necessary for the access point to find a list of available controllers with which it can associate.

The following layer 3 CAPWAP discovery options are supported:
1.       Broadcast on the local subnet
2.       Local NVRAM list of the previously joined controller, previous mobility group members, and administrator primed controller through the console port
3.       Over the Air Provisioning (OTAP) (subsequently removed in version 6.0.170.0 code)
4.       DHCP Option 43 returned from the DHCP server
5.       DNS lookup for "CISCO-CAPWAP-CONTROLLER.localdomain"

Broadcast
The CAPWAP AP sends broadcast discovery requests on the local subnet. Controllers with management interfaces on the same subnet receive the discovery request and send a discovery reply back to the CAPWAP AP.

If no controllers are on the local subnet, broadcasts may be forwarded to the controller management interface by the local router using the Cisco “forward-protocol” and “ip helper-address” features. Use these commands to configure the router:

ip forward-protocol udp 12223
ip forward-protocol udp 5246
interface interface-name
     ip helper-address wlc-management-ip-address

When using the forward-protocol, the default gateway modifies the CAPWAP discovery packet that is broadcast on the local subnet by replacing the broadcast destination IP address 255.255.255.255 with the WLC management IP address configured as an IP helper-address, then routes the packet to the controller. The downside to this approach is that the WLC will also receive all other forwarded protocols such as DHCP discovery packets. Also, other configured IP helpers will receive the CAPWAP discovery packets. Since this behavior is likely undesired, be sure to use the forward-protocol method only temporarily.

Local NVRAM
The local NVRAM of the access point stores a list of controllers, gathered from the following sources:

·         Primary, Secondary, and Tertiary controller preferences previously configured for the AP

If the access point was previously associated to a controller, the IP addresses of the primary, secondary, and tertiary controllers are stored in the access point’s non-volatile memory. This process of storing controller IP addresses on access points for later deployment is called priming the access point.

To verify locally stored controller preferences:

show ap config general ap_name

Primary Cisco Switch Name........................ WLC001
Primary Cisco Switch IP Address.................. Not Configured
Secondary Cisco Switch Name...................... WLC002
Secondary Cisco Switch IP Address................ Not Configured
Tertiary Cisco Switch Name....................... BACKUP-WLC
Tertiary Cisco Switch IP Address................. Not Configured

·         Mobility Group Members from the previous controller connection

The AP also maintains previously learned WLC IP addresses locally in NVRAM. The AP sends a unicast CAPWAP Discovery Request to each of these WLC IP addresses. These WLC IP addresses are learned by the AP from previously joined controllers. The stored WLC IP addresses include all of the WLCs in previously joined controller mobility groups.

To verify locally stored controllers learned through mobility groups, console into the access point and enter the following command:

show capwap client config

mwarName                CCIETEST
mwarName                backupwlc
mwarName
numOfSlots              2
spamRebootOnAssert      1
spamStatTimer           180
randSeed                0x9640
transport               SPAM_TRANSPORT_L3(2)
transportCfg            SPAM_TRANSPORT_DEFAULT(0)
initialisation          SPAM_PRODUCTION_DISCOVERY(1)
ApMode                  Local
Discovery Timer         10 secs
Heart Beat Timer        30 secs
Led State Enabled       1
AP ILP Pre-Standard Switch Support Enabled
AP Power Injector Disabled
Infrastructure MFP validation Enabled
Configured Switch 1 Addr 10.127.78.5
Configured Switch 2 Addr 10.108.50.20


Note – mwarName entries are the controller preference settings (primary, secondary, tertiary). Configured Switch entries are the learned mobility group members.

·         Manually primed controller IP address through the console

Manual configuration can be used to “prime” the CAPWAP if network services for address assignment and WLC discovery do not exist. If the CAPWAP has previously joined a controller, or is currently joined to a controller, these commands will be disabled.

To stage an access point, use the commands:
capwap ap controller ip address wlc-mgmt-ip
show capwap ip config

OTAP
If this feature is enabled on the controller, all associated access points transmit wireless RRM neighbor messages, and un-joined access points can receive the controller IP address from these messages. This feature is disabled by default and should only be enabled when necessary for AP deployment.

Note – OTAP does not work with default APs out of the box or upgraded using the Upgrade Tool because the radios are disabled from the manufacturer. 

Configure OTAP:
config network otap-mode { enable | disable }
show network summary

Note - OTAP was removed from the wireless controller feature set in code version 6.0.170.0 due to a vulnerability.

DHCP Option 43
The IP address that should be configured as DHCP option 43 is the address of the controller Managament interface.

Cisco 1000 series access points use a string format for option 43.
Cisco Aironet access points use the type-length-value (TLV) format for option 43.

DHCP servers must be programmed to return the option based on the access point’s DHCP Vendor Class Identifier (VCI) string (DHCP option 60). The VCI strings for Cisco access points capable of operating in lightweight mode are listed in the following table:


The format of the Option 43 TLV block is:
     Type: 0xf1 (decimal 241)
     Length: Number of controller IP addresses * 4
     Value: List of WLC management interfaces

Configuration of option 43 will vary by DHCP server platform. Here is an example configuration using the built-in Cisco IOS DHCP server:

ip dhcp excluded-address start-ip end-ip
ip dhcp pool 
pool-name
     network ip-address netmask
     default-router ip-address
     
dns-server ip-address … ip-address
     domain-name domain
     lease days hours
     option 60 ascii VCI string
     option 43 hex hex-value

An example of a finished IOS DHCP server configuration will look similar to this:

interface Vlan192
 ip address 192.168.1.1 255.255.255.0

ip dhcp excluded-address 192.168.1.1 192.168.1.10

ip dhcp pool lwapp
   network 192.168.1.0 255.255.255.0
   default-router 192.168.1.1
   dns-server 192.168.1.2
   domain-name test.lab
   lease 7
   option 60 ascii "Cisco AP c1240"
   option 43 hex f108.0a6c.3214.0a6c.3212

In this example, the hex value is obtained from these TLV values:

Type = 241 (0xf1)
Length = 2 IP addresses * 4 bytes each = 8 bytes (0x08)
Value = 10.108.50.20 (0x0a6c3214) and 10.108.50.18 (0x0a6c3212)

Note – Periods are added automatically to the hex value by Cisco IOS and should not be entered by the administrator when entering configuration commands.

DNS
The AP will attempt to resolve the DNS name “CISCO-CAPWAP-CONTROLLER.localdomain”. When the AP is able to resolve this name to one or more IP addresses, the AP sends a unicast CAPWAP Discovery Request to the resolved IP address(es). The DNS entries can be either an A (address) or CNAME (alias) records.

If the AP received a DHCP address, ensure the DHCP server is configured to return valid DNS servers and a valid domain name suffix to the AP.

If the AP is using a static IP address, configure the domain name and DNS name servers from the controller. WLC version 4.2 requires configuration from the CLI, whereas 6.0 and later allow configuration from the GUI. Once applied, the AP will disconnect and re-join the controller.

config ap static-IP { enable | disable } ap_name ip_address netmask gateway
config ap static-IP { add | delete } domain { all | ap_name domain_suffix
config ap static-IP { add | delete } nameserver { all | ap_name dns_server_ip_address

Verify the configuration of the AP:

(Cisco Controller) > show ap config general ccielwap

IP Address Configuration......................... Static IP assigned
IP Address....................................... 10.108.51.54
IP NetMask....................................... 255.255.254.0
Gateway IP Addr.................................. 10.108.50.1
Domain........................................... ccietest.com
Name Server...................................... 10.10.10.25

Verification of Method Used
To view the method used by an AP to discover the controller, view the console output of the AP as it searches, or issue the following command from a controller that receives the discovery request and search for IE 58 from the AP which indicates the discovery method used to resolve the controller IP address:

debug capwap packet enable

CAPWAP Discovery Packet IE 58 values:

0 = Broadcast
1 = Local NVRAM
2 = OTAP
3 = DHCP
4 = DNS

Example 1 – AP Console Log indicates DHCP discovery

*Mar  1 00:00:30.287: Logging LWAPP message to 255.255.255.255.
%DHCP-6-ADDRESS_ASSIGN: Interface FastEthernet0 assigned DHCP address 192.168.1.20, mask 255.255.255.0, hostname AP0018.7361.e702
Translating "CISCO-LWAPP-CONTROLLER.test.lab"...domain server (10.97.40.216)
%LWAPP-3-CLIENTEVENTLOG: Performing DNS resolution for CISCO-LWAPP-CONTROLLER
%LWAPP-3-CLIENTERRORLOG: DNS Name Lookup: could not resolve CISCO-LWAPP-CONTROLLER
%LWAPP-3-CLIENTEVENTLOG: Controller address 10.108.50.20 obtained through DHCP
%LWAPP-5-CHANGED: LWAPP changed state to JOIN
%LWAPP-5-CHANGED: LWAPP changed state to CFG
%LWAPP-5-CHANGED: LWAPP changed state to DOWN
%LWAPP-5-CHANGED: LWAPP changed state to UP
%LWAPP-3-CLIENTEVENTLOG: AP has joined controller CCIETEST

Example 2 – WLC LWAPP Packet Debug indicates DHCP discovery

(Cisco Controller) > debug lwapp packet enable

Mon Feb 22 09:55:32 2010: Start of Packet
Mon Feb 22 09:55:32 2010: Ethernet Source MAC (LRAD): 00:17:DF:96:9F:90
Mon Feb 22 09:55:32 2010: Msg Type       :
Mon Feb 22 09:55:32 2010:    DISCOVERY_REQUEST
Mon Feb 22 09:55:32 2010: Msg Length     :   31
Mon Feb 22 09:55:32 2010: Msg SeqNum     :   0
Mon Feb 22 09:55:32 2010:
IE            :   UNKNOWN IE 58
Mon Feb 22 09:55:32 2010: IE Length     :   1
Mon Feb 22 09:55:32 2010: Decode routine not available, Printing Hex Dump
Mon Feb 22 09:55:32 2010: 00000000: 03                                       Mon Feb 22 09:55:32 2010:

In my next post, I will describe the controller selection process used by the wireless access point to determine which controller to establish a connection to when multiple controllers have been discovered.

Prior to selecting a controller, the access point always performs discovery using the methods listed above. From the discovery responses the AP builds a list of candidate controllers and selects the optimal controller.

Cheers,
Andrew

CAPWAP Split-MAC Architecture Overview

One of the key principles behind the LWAPP and CAPWAP protocol architecture is the notion of a split 802.11 media access control. Since the real processing power and smart feature set of the architecture is implemented in controllers, some functions need to be performed in the controller instead of the access point. This concept is called "Split-MAC" by Cisco and most other controller-based vendors.

The AP and controller are linked by the CAPWAP protocol using both a "control" channel for access point management, configuration, and control, and a "data" channel for forwarding of user traffic between the two entities in the cases where user traffic is tunneled all the way to the controller (central bridging). These two channels are nothing more than CAPWAP encapsulated UDP packets using port 5246 (control) and 5247 (data) since Cisco code version 5.2. Earlier versions of code used the LWAPP protocol, which was CAPWAP's predecessor, and use UDP ports 12223 (control) and 12222 (data).

It is important for wireless engineers designing, deploying, administering, and troubleshooting solutions using this type of architecture to understand the functions carried out by the controller versus the access point.

The industry is currently in a transition back to a de-centralized model, with local data bridging coming into higher demand as 802.11n data rates strain controller bandwidth capacity and branch offices struggle to cost-justify the additional expense of controllers. This is evident with the emergence of Cisco H-REAP, Aruba RAP, Motorola Adaptive APs, and taken to the extreme by Aerohive in their controller-less architecture. This trend will only continue, but engineers will still be required to fully understand the split-MAC concept even under these circumstances as the large vendors are likely to require centralized controllers for some control-plane functions.

The split-MAC functionality is divided between controller and AP in the following fashion:

Controller Responsibilities:

  • Security management (policy enforcement, rogue detection, etc.)
  • Configuration and firmware management
  • Northbound management interfaces
  • Non real-time 802.11 MAC functions
    • Association, Dis-Association, Re-Association
    • 802.11e/WMM Resource Reservation (CAC, TSPEC, etc.)
    • 802.1x/EAP Authentication
    • Encryption Key Management
  • 802.11 Distribution Services
  • Wired and Wireless Integration Services

Access Point Responsibilities:

  • Real-Time 802.11 MAC Functions
    • Beacon generation
    • Probe responses
    • Informs WLC of client probe requests
    • Power management and packet buffering
    • 802.11e/WMM scheduling and queuing
    • MAC layer data encryption and decryption
    • 802.11 control messages (ACK, RTS/CTS)
  • Data encapsulation and de-capsulation via CAPWAP
  • Fragmentation and re-assembly
  • RF spectral analysis
  • WLAN IDS signature analysis

In future posts, I detail how CAPWAP APs discover, select, join, and maintain association with a controller.

Cheers,
Andrew

Wednesday, November 17, 2010

Cisco WLC QoS Profile Bugs

There is a pretty devious little bug ID in the Cisco WLC QoS profile settings that can lead to problematic traffic forwarding for users and a pretty severe disruption to user experience.

Recently, during a guest wireless deployment, our wireless engineering team designed a solution to minimize potential impact of guest Wi-Fi devices on our production network by implementing QoS bandwidth contracts to guest users. This is accomplished through the Wireless > QoS > Profiles section of the wireless controller configuration, as shown below.


When this QoS profile is applied to a WLAN, each user's bandwidth is limited to the specified average and burst data rates (in Kbps). Additionally, the wired QoS protocol tagging feature uses 802.1p for layer 2 class of service integration with the wired network switches.

Once implemented, we began experiencing random TCP sessions dropping as well as random UDP packet loss. Scratching our heads, we started digging into what changed recently. Besides upgrading to 7.0.98.0 code, the only other change was enforcement of QoS bandwidth contracts using the Bronze QoS profile applied to the guest wireless WLAN. It also happened that the guest user base were the only individuals reporting problems. They were having IPSec and SSL VPN sessions dropping numerous times throughout each day. Definitely not a productive environment to support many corporate business partners whom we rely on to help us get work done.

Many packet traces at *multiple* points throughout the network later, we found return packets to clients missing, and apparently being dropped by the local controller. We expected that tracing packets in both CAPWAP and Mobility Ether-IP tunnels would be fairly complex, but were pleasantly surprised to see that Wireshark had protocol dissectors for both protocols! Yeah Wireshark!

Also, having a network of remote sniffers deployed throughout various points in your network is a godsend for remote configuration and packet capture capabilities. Thank you to our internal performance services team for having this capability! I can only imagine how painful it would have been to have to physically visit each point in the network to setup a SPAN port or other manual network sniffer solution.

So, knowing the local controller (as opposed to the DMZ anchor, or any other network equipment) was dropping the packets, it was a fairly simple matter of figuring out what changed to cause the issue. Rather than downgrading code, we first reverted the configuration to it's state prior to the problems by removing the QoS bandwidth contracts. Voila, problem magically disappeared.

Searching the Cisco documentation of this feature revealed no clues or warnings around best practice use of this feature (normally, if Cisco does not want a customer to modify a default value without contacting TAC or Advanced Services they will explicitly state that in the configuration guide). No warnings, okay - what is going on here, why is this feature not working correctly. Hmmm.... BUG?!

How about that, numerous bugs exist for the QoS profile settings for 802.1p tagging and bandwidth contracts. Here's one interesting one:

CSCsz20162 - WLC5500: QoS rate limiting feature is not accurate
This bug was resolved in 7.0.98.0 code, or was it?

Additionally, here are some other bugs not fixed until code versions after 7.0.98.0 (all fixes apply to a later release of code):

CSCth94887 - 5500: 802.1p markings not working for pings, EoIP and FastCache mode
CSCth90962 - Document QoS 802.1p tagging blocks traffic on untagged interfaces
CSCte64638 - Clients cannot ping or get IP address with 802.1p QoS profile
CSCti62070 - Per-User bandwidth contract blocks all traffic when set to 0
CSCte53175 - Per-User bandwidth contract blocks all traffic when set to 0

None of these directly relate to our issue, but there are enough bugs on the feature to make me think I may have found a new one. Additionally, since our issue cleared right up when removing the bandwidth contracts, a bug seems to be the likely bet here.

I also find it interesting that Cisco's Bug Toolkit does not include lookups for their 5508 series wireless controllers. So I'm stuck looking up bugs for the 4400 series, hoping that everything affecting 5508's also affects 4400's.

As Ethan Banks posted over in his blog, engineers are constantly opening support cases with vendors for bugs. "All the bugs. All the time, bugs. Bugs and bugs and bugs. Buggy bug bugs. AHHH!" I can relate to that.


So, what have we learned from this experience?
  1. Document all changes to systems. There is a reason that change management practices and processes exist in most organizations. Use it, live by it, it will save your butt.
  2. Test your changes prior to production implementation. We did test this change and still failed to catch the issue. But we will update our testing procedures. We catch most issues with testing, but some still fall through the cracks. Learn from them and update your testing plans accordingly.
  3. Prepare troubleshooting tools ahead of time. Without remote packet capture capability, it might have taken us 10x longer to figure out where the issue was occurring. We had new addressing space, routing, firewalls, proxies, etc. all involved that I didn't discuss for brevity, but it could have been anywhere. Take a pro-active approach to deploying troubleshooting and monitoring tools. This way, when a problem comes up you can react quickly and execute on an emergency response plan. They do this for fire drills and emergency responders, take the time to do it for your network!
  4. Admit mistakes, take responsibility, and fix the issue. I've seen too many individuals in IT attempt to deny issues and gloss over relevant information for fear of looking bad, incompetent, or just plain "not perfect" at what they do. Some even go so far as to lie about log data (or selectively focus on data that reinforces their position while discounting data that does not). This leads to longer issue resolution times, worse business impact, and once the root cause is determined, which it will be, they end up losing credibility and trust of everyone involved. Instead, present all data that could possibly be involved in the issue up front, and if it is your issue take responsibility. Everyone makes mistakes or simply cannot do a *perfect* job. Even the best engineers, including CCIEs (yes, you're fallible too)!
For the time being, I would recommend avoiding per-user bandwidth contracts in your wireless LAN controller QoS profiles. 


Best of luck out there with your bugs ;)
Andrew

Monday, November 15, 2010

Nuts About Nets AirHORN Overview

AirHORN is an RF signal generator capable of transmitting standard Wi-Fi modulated signals on the 2.4 GHz and 5 GHz ISM and UNII bands.

*Note – AirHORN does not support signal transmission in the 5GHz UNII-3 and ISM band (5.725 – 5.875 MHz).

The dual-band version of the product comprises a single USB adapter with internal antenna and a USB mount with cable extender for optimal device orientation and polarization. The single-band version comes with an external RP-SMA connector and 5dBi omni-directional antenna, offering the flexibility to use alternate external antennas. Installation of the product requires an available USB 2.0 port and Microsoft .NET 2.0 Framework. Older laptops and workstations with USB 1.1 ports will not work properly and the software will not initialize.


AirHORN is useful for RF antenna engineers when researching and developing wireless antenna propagation, amplifier performance, and receiver operation to ensure accurate signal transmission and reception according to desired specifications. It can also be used post-manufacture by wireless LAN engineers when designing and installing Wi-Fi networks, and is especially useful for directional and semi-directional antenna alignment. It can also be used in the absence of a Wi-Fi access point during pre-installation site surveys to identify optimal AP placement for complete RF coverage assessment as well as to avoid RF dead spots.

The signal generated by AirHORN is viewable with any spectrum analysis tool, such as the Cisco Spectrum Expert as shown in this demonstration.


Another good use for AirHORN is to combine its use with other network performance evaluation tools, such as NetStress, IxChariot, or Iperf to determine the negative impact that co-channel interference (CCI) and adjacent channel interference (ACI) can have on a Wi-Fi network from other RF sources. When combined, these tools can be used as a valuable training classroom lab aid to demonstrate these concepts to inexperienced wireless LAN engineers, to identify and measure the effects of neighboring RF impact to a Wi-Fi network, to generate impact assessment reports for management, and develop internal best practices around AP placement and channel overlap to minimize negative impact.

The product can also function as a denial of service (DoS) tool to cause severe disruption to a wireless LAN network since it utilizes 100% of available airtime (duty cycle). The signal generated by AirHORN is capable of completely wiping out a Wi-Fi network. However, the product is specifically designed to comply with all FCC regulations and IEEE standards for power output and transmission power is limited to 17dBm (50 mW). Also, AirHORN causes performance degradation in part because the signal transmission does not adhere to IEEE 802.11 medium contention rules and acts as a continuous transmitter.

Wireless LAN engineers should know that the tool is not automatically classified by Cisco CleanAir spectrum analysis access points. This is due to the CleanAir system architecture which splits RF signal processing between the Wi-Fi chipset and the SAgE spectrum chipset, with the focus of the SAgE chipset on non-Wi-Fi interference classification. The Wi-Fi modulated AirHORN RF signal is sent to the Wi-Fi chipset and are not processed by the SAgE chipset, with the resulting energy being interpreted as Wi-Fi adjacent channel interference and contributing to overall channel utilization. Therefore, the SAgE chipset and CleanAir system cannot classify the signal.

Product Link:

Cheers,
Andrew

Monday, November 8, 2010

Wake on Wireless LAN

Let me just get this out of the way - you will not implement Wake on Wireless LAN. I'm not hating on the technology, in-fact I think it's pretty cool. The simple fact is that there is not enough industry support for WoWLAN to make it feasible for most organizations.

However, WoWLAN is an interesting case study as more organizations move toward a mobile workforce where wireless networking is their primary connection. It provides insight into what technical hurdles must be crossed to achieve "Green IT" in a wireless world, provides lessons learned for organizations considering the "all-wireless" jump, and hopefully will compel large organizations to apply pressure to industry manufacturers to develop a suitable replacement technology.

WoWLAN Overview
Similar to Wake-on-LAN (WoL), Wake on Wireless LAN (WoWLAN) is a technology that allows remote wake-up of workstations from a standby power state to facilitate device management. WoWLAN is based on the well-established WoL standard used over wired Ethernet networks, and can provide similar functionality and benefits.

However, functionality is not entirely equivalent to WoL and there are a few serious limitations that may prevent organizations from considering WoWLAN a viable technology.

Benefits
The ability to place workstations into a low-power mode provides one primary benefit to the organization, reduced facilities operational expenses. Green IT initiatives are pushing most organizations to find operational areas where energy consumption can be reduced, either through process improvement, equipment consolidation, or virtualization.

One primary method organizations are achieving these savings are through smarter workstation power management practices. Purchasing Energy Star certified equipment and minimizing device power draw during off-hours allow organizations to save a considerable amount of money.

Consider that desktops consume between 100 - 250 Watts when powered on, and around 2 - 6 Watts when in sleep/standby. On the other hand, laptops require between 15 - 60 Watts of electricity to run when active, but only around 1-2 Watts when in sleep mode. That difference can translate into a large amount of savings just by placing devices into sleep/standby mode when no one is using them. Assuming the typical office worker is using the workstation for only 8-10 hours/day, most organizations could safely place the machines into sleep mode for 14-16 hours.

Let's take an example using a laptop, since that will be the primary use-case for WoWLAN. We'll use a Dell Latitude D630, a common corporate laptop for the masses. This particular model consumes 46.87 Watts active, and 2.04 Watts in standby mode. Let's also assume that this is a large organization with an inventory of 5,000 laptops and is paying $0.10 / kW-hour.

Prior to implementing the standby mode policy, energy consumption would have been:
     ( 46.87 W * 24 hours * 365 days / 1,000 W/kW ) * $0.10 * 5,000 laptops = $205,290/year

After implementing the policy, assuming a 9 hour work day, laptops will be placed in standby mode for 15 hours each day:
     [ ( 46.87 W * 9 hours) + (2.04 W * 15 hours ) ] * 365 days / 1,000 W/kW * $0.10 * 5,000 laptops = $82,568/year

Net Savings = $122,722/year (roughly 59% reduction in energy expense)

Technology Drivers
So, why not just implement our laptop standby policy, claim the expense reduction, pat ourselves on the back, and be done with it? Because most invasive IT processes run overnight when there is no user to impact. Just leaving a device in standby mode will cause all sorts of processes to break in almost any organization, big or small.

Some of the functional requirements for implementing Wake on Wireless LAN solutions include the following:

- Security Patching - typically scheduled for installation after business hours to reduce the impact to employees, security patching is one of those functions that needs to happen. Period. Running updates during the day is a quick way to frustrate and de-motivate employees. Even worse is scheduling it overnight, only to have a contradictory policy placing all workstations in standby every night preventing the patches from installing until the next morning when the employee returns to work and powers it back up. That's a quick way to make the IT department look incompetent and a major pain in the rear!

- Remote Desktop Access - some organizations support remote access for employees through a home computer with limited access to internal resources. Broader access can be granted by giving employees the ability to remote desktop into their corporate owned workstation sitting at work. This allows more functional access while maintaining close control over data exposure. In order to remote into the system, a method to wake it back up must be provided and reliably executed.

- All-Wireless Network - many organizations are now purchasing laptops rather than desktops for their employees for a variety of benefits, including mobility and productivity. This is shifting network traffic from wired to wireless networks, and thus places additional requirements on wireless solutions than previously existed. Deploying an "all-wireless" office is reasonably possible using Wi-Fi networks today, requiring equivalent functionality of a wired network.

How it Works
Wake on Wireless LAN works very similarly to traditional WoL solutions. Components include a network management application software suite that provides workstation inventory and central policy controls, a master workstation on each broadcast domain (subnet) which is selected by the management suite, and the use of broadcast "magic" packets used to wake up the remote system.

Here is a sample wireless magic packet (download for reference):


Although the example above shows an unencrypted magic packet, the security of the frame will be dictated by the network policy attached to the wireless network. Therefore, broadcast frames including magic packets will be encrypted using the GTK (Group Temporal Key). Therefore, wireless workstations in standby mode need to remain associated to the BSS in order to properly receive the magic packet. Although subtle at first, this requirement has a pronounced effect on workstation behavior while in standby mode, forcing the wireless NIC to come out of power-save mode in order to send traffic and maintain status in the BSS at regular intervals. A "listen-only" approach is no longer sufficient. This behavior also impacts the power consumption of the workstation, and although not large amounts of power are required, over a period of time such as several hours this could drain a laptop batter dry (especially an old battery).

In order to support WoWLAN, the wireless infrastructure will need to be configured to allow broadcast wireless frames to traverse the network. Newer enterprise class wireless networks typically have advanced features that filter broadcast frames by default to improve performance of the network. That feature will need to be disabled to allow WoWLAN to function properly.

Enterprise class systems generally integrate well with DNS for workstation resolutions and wake-up, rather than relying on users to identify workstations by MAC addresses. This enables usability of the solution for employees.

Typically a wired workstation will be selected in the broadcast domain to serve as the master workstation due to preference for higher bandwidth workstations, especially if connected via gigabit Ethernet.

Configuration of the workstation's wireless adapter is required in order to allow the adapter to wake the system from a standby or low-power state. This is accomplished on Windows machines through the adapter properties dialog:

Additionally, most WoL management suites provide workstation agents that can run in the background to check-in to the management application for inventory, policy updates, as well as to allow the employee to override the corporate settings for a limited amount of time when necessary. An employee portal or tool front-end is usually also supplied to allow remote wake-up through a web interface that is easily accessible.

To wake up a machine, the employee logs into the web portal, enters the workstation DNS name or selects it from a list and confirms the selection. On the back-end, the management workstation queries the device in DNS and within it's inventory to discover it's current IP subnet and stored MAC address. The master workstation for the subnet is then contacted to begin transmitting the magic packet for a pre-determined interval. The packet is sent out the wireless LAN during the next DTIM period, during which the wireless workstation awakes from power-save mode upon seeing queued broadcast traffic indicated in the DTIM beacon and receives the magic packet instructing the workstation to fully wake from standby.

Having tested this setup, I can say this process works successfully.

Limitations
Although functional, WoWLAN does have some serious practical limitations. These limitations are fairly significant, and will likely prevent many organizations from deploying WoWLAN.

- Integrated Adapters Required - The wireless adapter is required to be integrated onto the motherboard in order to control the power state of the workstation (this category also includes mini-PCI and mini-PCIe adapters). Newer motherboards and plug-in wireless adapters do not have the required power connector and cable as some older systems provided. Therefore, external adapters that are not integrated into the motherboard will not be able to control the power circuity and thus cannot support WoWLAN.

- Limited On-Board Adapter Support - Notably, I have found that Intel adapters are the only ones which support WoWLAN. I am unaware of any other chipset manufacturer currently providing support for this feature. This is easily identified on Windows machines by checking for the presence of the power management tab and settings within the wireless adapter properties.

- Standby Mode Only - Because wireless clients must remain connected to the BSS at all times, standby mode is the lowest power state supported. Hibernation or full power off states will not work because no power is provided to the wireless NIC to maintain network association.

- AC Power State - During testing, one curious behavior seemingly played tricks on me for quite some time. It appears that power control of laptops by wireless adapters is quite sensitive to the AC power state. Wake-up from standby only appears to work when the laptop is placed into standby mode while connected to an AC electrical source and remains connected to that source until woken. If the laptop is removed from AC power while in standby, or initially placed into standby mode while on battery power, WoWLAN is ineffective. After thinking about this one, it is fairly logical to conclude that WoWLAN requires a certain amount of power draw by the wireless NIC to remain associated, possibly prompting concerns over battery life and integrity if WoWLAN were allowed to function while on battery power alone. Whatever the case, AC power is required at standby initiation and throughout the duration of low-power state.

- Negative Performance Impact - Allowing broadcast wireless frames across the wireless network will reduce network performance. This is an unfortunate side effect, but one that cannot be avoided. However, through proper architecture the negative impact can be greatly minimized. This includes blocking wireless client to client communication and isolating wireless clients on their own broadcast domain to minimize potential broadcast packets to the default gateway and potentially one wired master workstation for the subnet (strategically deployed by an administrator of course).

Conclusions
While technically feasible, Wake on Wireless LAN is saddled with severe limitations and lack of industry support. It is doubtful that most organizations could even consider a WoWLAN deployment unless running an environment composed entirely of Intel wireless adapters.

However, it appears that Intel has used its WoWLAN experiences and is bundling comparable functionality into its vPro feature line. Newer adapters that are vPro compatible (such as the Intel 6200 and 6300 models) claim to offer wireless system manageability and remote repair even when the system is in a completely powered off state. I suggest reading the vPro whitepaper linked above. It also clearly identifies the AC power state is still required to remotely wake a wireless client.

WoWLAN appears to have been a technology that missed wide adoption, but lives on through the learnings it provided. vPro stands ready to fill the gap, but requires newer hardware. I guess it's time to diligently update workstation requirements and purchase accordingly moving forward.

Additional Resources
Intel WoWLAN Technical Brief (Sorry for the 3rd party website link. Intel seems to have pulled this tech brief off their website. Not a good sign!)

Cheers,
-Andrew

P.S. - If any has any WoWLAN experiences, I would love to hear about it. Please share your testing, results, and success / failures with this feature.

Tuesday, November 2, 2010

Firesheep Fallacies and Practical Advice

Firesheep is a threat, but not in the way you have heard from most mainstream news sources. Most of the mainstream media is ‘spinning’ the Firesheep story completely wrong, attempting to pin open Wi-Fi hotspots as the wolf dressed up in sheep’s clothing.

They’re wrong.

Firesheep is NOT an issue with open Wi-Fi, it is an issue with application security as implemented by many content providers and website owners.

… here’s why

Firesheep’s Elder Sibling, Sidejacking
Listening to the news last week, Firesheep would appear to be a catastrophic new attack. However, it’s not new. Back in 2007 Robert Graham presented at the Black Hat security conference and introduced the sidejacking attack. What’s more, it wasn’t a theoretical attack, it was real. He released two tools called Ferret and Hamster to exploit website cookies in an easy point-and-click fashion.

What’s interesting about the 2007 sidejacking exploit is not the attack itself. Cross-site scripting and man-in-the-middle (MiTM) attacks have been around for years in multiple fashions. No, what’s interesting to me was the response to the attack (or lack thereof). As security goes, new exploits are always coming out. It’s literally a cat-and-mouse game all the time between hackers and defenders.

The lack of action and dismissal of the sidejacking attack by almost every major service and content provider, as evidenced by their vulnerability to Firesheep, shows that the lack of accountability for consumer data protection by businesses, and results in weak and poorly designed information systems. It’s been 3 years since sidejacking came out, why are we still in the position as consumers of being vulnerable to this attack?

As a customer of many of these businesses, I’m dismayed (even angered) at their lack of corporate responsibility and apparent disregard for consumer data privacy and protection.

Crying Wolf over Open Wi-Fi Hotspots
Open Wi-Fi hotspots are the easy scapegoats in this story. Due to the history of poor wireless security (WEP) and scrutiny attached to Wi-Fi network security, including wireless as a buzzword in a story headline is an easy way for media outlets to draw attention and readers to their content, which ultimately helps drive their bottom-line through advertising and sales.

Yes, open Wi-Fi networks carry certain trade-offs for consumers. However, they are generally worth the risk for most people. And it is our job as industry professionals to strike an appropriate balance between usability of service offering and security. That balance can easily be met on open Wi-Fi networks by applying proven technologies, such as SSL session encryption for secure public content, built-in device firewall capabilities, and VPN software deployment on corporate assets, just to name a few. These are all proven technologies that are not new to the marketplace.

Open Wi-Fi networks themselves are not the risk, it’s how providers often fail to properly architect the systems and applications that run over these networks that lead to problems.

Encrypted Wi-Fi Doesn’t Mitigate the Underlying Issue
Most reporting is claiming that encrypting the wireless hotspot network will solve the Firesheep issue and protect consumers from the evil hackers. This couldn’t be further from the truth.

Basic encryption, in the form of WPA or WPA2 pre-shared key provides no user authentication and actually very minimal data privacy when used for public networks. In a public setting, hotspot operators typically offer the service to all patrons within their premises. In this environment, access to the network is usually free or readily attainable with minimal effort.  What’s less well understood by most is that a pre-shared key is the same for all users of the network and provides the ability for anyone with access to the network (ahem, everyone) to be able to decrypt and read any other user’s traffic. This is easily accomplished by de-authenticating a user and capturing the WPA 4-way handshake to reveal a user’s data encryption key.

More advanced encryption uses dynamic keying, resulting from 802.1x/EAP authentication to the network. However, even using unique encryption key material for each user will not be sufficient to stop hackers from using Firesheep and other MiTM attacks. That’s because authorized users on the network can employ other techniques to eavesdrop on traffic and bypass encryption privacy. Tools that manipulate network operation to re-route traffic through the attacker can enable MiTM attacks. The most common among them is ARP cache poisoning, whereby a hacker injects false addressing into the local network to make the client and router both think traffic should go through the hacker’s machine to reach its destination. Hole-196 is also another method of executing the ARP poisoning attack on wireless networks. Freely available and easy-to-use tools such as Cain & Abel and Ettercap can facilitate these attacks and have been around for a long time.

Ultimately, using either PSK or dynamic keying in public networks only serves to deter the casual eavesdropper. And casual eavesdroppers are NOT your worst threat, motivated hackers are. And they’re the ones who have spent the time and energy necessary to learn how to bypass these controls to accomplish their goals. Most organizations and security experts know that the worst threats on private networks are “insiders” who have access to the system. On public networks, everyone is an “insider”!

This is an important point, and bears repeating. Dedicated hackers are the biggest threat, and on public networks they are effectively authorized “insiders” to the system, no matter what encryption is being used.

Wired Networks are Vulnerable Too
Oh, by the way, Firesheep can be executed with great success on wired networks too. Funny how no reports have seemed to mention that fact.

Typically, wired networks aren’t public networks and have more strict physical security controls around who has access to plug into the network. However, most organizations have conference rooms full of unprotected LAN ports and allow most visitors unrestricted access to such ports once inside the facility. 802.1x/EAP authentication on wired networks is possible, but almost never implemented due to complexity in migrating legacy systems into such a model. Printers, scanners, phones, etc. don’t support authentication and just expect to get and IP address and work.

This means that it boils down to access into the facility to protect the wired network, and social engineering to gain access can usually be accomplished at all but the most restricted facilities. Once LAN port access is obtained, execution of ARP cache poisoning and MiTM attacks works just as easily as on any Wi-Fi network.

Minimizing Risk
So, now you know that open and encrypted Wi-Fi networks are still vulnerable, as well as wired networks. What steps can be used to minimize the threat?

On Wi-Fi Networks, coupling dynamic key encryption with broadcast traffic filtering, peer-to-peer blocking, wireless ARP proxy, and disabling gratuitous ARP on the router will help minimize the risk.

Dynamic key encryption provides data privacy unique to each user so other user’s only see scrambled data.

Broadcast traffic filtering is another common feature on enterprise-grade wireless solutions that limits broadcast traffic going out over the wireless network, typically to improve performance. However, it has the side benefit of preventing broadcast gratuitous ARP replies from being able to poison the ARP cache of all clients on the same network at once, which will severely limit a hacker’s ability to execute a MiTM attack on a large amount of users at once. Hackers can still target individual users one-by-one and poison their ARP cache individually.

That’s where peer-to-peer blocking comes into play. By enabling this feature, again standard on most enterprise-grade Wi-Fi solutions, hackers can no longer communicate directly with other clients and cannot poison their ARP cache. This prevents hackers from intercepting upstream traffic from the client to the default gateway.

Finally, disabling gratuitous ARP on the router will prevent the router from accepting ARP replies that it did not request (hence ‘gratuitous’). The only time a router will install an ARP entry into its table is when it requested it. When coupled with the wireless network performing ARP proxy for wireless clients, the wireless AP or controller will respond to ARP requests for its connected clients and prevent the hacker from being able to poison the router’s ARP cache. This effectively eliminates the ARP cache poisoning attacks.

On wired networks, enabling DHCP snooping and ARP inspection features can help minimize the risk.

DHCP snooping is a feature on higher-end enterprise switching products that enables the switch to learn the DHCP address assigned to clients and build a MAC address to IP address table dynamically. Building on top of the DHCP snooping binding table, enabling ARP inspection allows the switch to investigate ARP frames traversing the switch ports / VLANs on which the feature is enabled. The switch compares the expected MAC and IP address values in the ARP request and response frames to the DHCP snooping binding table to verify that the values match. If a client is found to be spoofing a value, the frame is dropped and a log message is generated to notify the administrator. This prevents hackers from being able to execute ARP cache poisoning attacks.

Shouldn’t Everyone Implement Secure Wi-Fi Hotspots?
For reasons discussed above, encrypted wireless networks alone still leave users at risk. And for public hotspot networks, encryption doesn’t matter if you let everyone onto the network (ahem, the basic premise of a hotspot in the first place).

Steve Gibson over at GRC.com has advised the use of WPA/WPA2-Personal (using PSKs), and Glenn Fleishman recommended going one-step further using WPA/WPA2-Enterprise (authenticated and uses dynamic encryption keying per-user). But they’re both wrong, implementing encryption doesn’t require hackers be able to break the encryption protocols to execute attacks on public networks. They can easily gain access to the network by simply requesting access from the hotspot operator. All they need to do is get onto the network, which is often freely available and happily provided in hotspot scenarios, and execute the relatively simple ARP poisoning attacks which most hotspot operators can’t protect against with consumer-grade Wi-Fi equipment, can’t afford to purchase enterprise-grade equipment to implement the necessary security features, or won’t be savvy enough to know how to protect against. And I don’t blame them; they are offering free Wi-Fi as a perk for customers and are often small businesses that lack technical expertise.

Fundamentally, though, not all hotspot business models are created the same. Applying encryption using either pre-shared or dynamic keys may aid the situation for some hotspot operators, but there are also a large number of hotspot operators for which encryption is not appropriate and does not fit the required business model. Often times these advanced hotspot operators are looking to provide more than just Internet access as a customer perk by developing customer loyalty programs and mobile marketing campaigns using highly localized and relevant (personalized) customer information. For these hotspots, knowing the customer (authentication) is required to provide tailored customer interaction and enhance the value proposition of offered services.

The emergence of mobile devices as a primary information consumption medium and the increasing need to integrate advanced application intelligence into mobile platforms such as smartphones, places added premium on making hotspot solutions usable for the consumer. Requiring strong authentication using 802.1x/EAP is still non-intuitive for the average user and makes connecting to the service painful to point that most consumers may not feel it’s worth the effort. Usability of the solution is paramount to creating an effective business model for the provider and ensuring adoption of the service by the consumer. If the operational requirements are too high of an effort for the consumer to overcome, then the value proposition fails in their eyes and so too does the business objective.

“Secure Open Wireless”
In addition, the IBM ISS X-Force team has proposed using publicly signed certificates to provide secure authentication and dynamic keying for public Wi-Fi hotspots. Providing signed certificates by a publicly trusted 3rd party (VeriSign, for example) is a proven method for implementing website security on the Internet. They propose extending the use of publicly signed certificates for wireless use. In theory this is reasonable, but there are limitations in products on the market today that will prevent this from working.

When using a browser to access a secure website, the server sends the client its certificate which has been signed by the mutually trusted 3rd party. Several things must occur for the client to accept this certificate without issue:
  1. The URL the client is accessing must be the same as the Common Name (CN) of the certificate
  2. The certificate validity period must include the current date
  3. The certificate must be signed by a trusted Certificate Authority (or Intermediate CA) for which the client has the Root CA certificate in its certificate store. All modern devices included a built-in list of trusted Root CAs.
  4. The certificate presented must not be on the Root CA’s Certificate Revocation List (CRL), which would indicate that the CA has revoked the server certificate due to compromise.
However, network supplicants don’t work exactly the same as the browsers. Whereas browsers rely on DNS to resolve URLs to server IP addresses and there is a clear correlation between the client’s intended destination URL (DNS name) and the Common Name presented in the certificate, no such correlation exists when network supplicants attempt to connect to a wireless SSID. The link between the advertised network SSID and the owner of the presented certificate is effectively broken since there is no way to distinguish what entity should own a given SSID name.

 If I connect to an SSID named “XYZ Free Wi-Fi” and am presented a certificate with a CN of “hotspot.xyz.com”, how is the client to determine the rightful owner of the SSID? The network could just as easily present a certificate with CN of “attacker.evil.net”. Both certificates may be valid and signed by a trusted 3rd party Root CA, but there is no link between the SSID and the certificate for comparison.

Because of this, network supplicants today don’t blindly trust any publicly issued certificate. CA trust must me manually configured on the client. I have installed Wi-Fi networks with public certificates purchased from and signed by 3rd party public CAs. Every client network supplicant still throws an alert and prompts to the user to validate the certificate prior to accepting. In corporate settings this is manageable because the IT department can dictate the configuration and CA trust settings for the client machines without involving the end users. For public hotspots, this puts the consumer in the position of determining if the certificate is valid for the network they are connecting to. Most users have no clue what a certificate is, let alone if it is valid. Even savvy IT professionals would have no way of correlating a certificate to an SSID even if they know what they are looking at. This promotes bad behavior of just clicking to accept whatever message pops up on the screen to get connected. That is not security!

IBM’s proposal is to use the DNS name as the SSID and then modify client network supplicant software to check that the SSID name matches the CN of the certificate, similar to how a browser checks the URL against the CN. This would work, but is ugly. All SSID names would then look like DNS names. Additionally, it would require time for all client manufacturers to upgrade their network supplicant software to include this functionality, as well as for network operators to migrate to the new naming convention.

There’s also the issue of checking the CRL list to determine if a certificate has been revoked. For browsers this is perfectly feasible since the client machine is connected to a network that presumably has Internet connectivity to request the CRL list from the CRL URL in the Root CA certificate. However, this becomes a chicken-or-the-egg scenario when applied to network supplicants. The client is attempting to verify the validity of the certificate without having network or Internet access, and thus cannot request the CRL, and must accept the certificate and complete authentication before being granted Internet access. What to do? There are no good options unless the network allows a “walled-garden” access to the CRL location prior to completing authentication. That works for Layer 7 authentication methods such as captive portal where the client has already obtained an IP address and can query other hosts over the network. In Layer 2 authentication scenarios a possible solution would be to adapt the 802.1x/EAP exchange to include request and retrieval of CRL information through the authentication server acting as a proxy. Since the CRL is signed by the Root CA, the client should be able to identify any tampering occurred.

/new-idea
An alternative method might be to create an SSID registry, similar to the DNS registry, by which corporations and individuals may purchase rights to use a particular SSID. The X.509 certificate format would need to be updated to include an SSID extension field, and public Root CAs would have to abide by rules to only issue certificates with a particular SSID after verifying the requester owns the SSID by checking the SSID registry. I like this idea better, but maybe that’s too much work.
/end-new-idea

Any way you look at it, today’s authentication options are not usable without 802.11u and new “Secure Open Wireless” solutions would take time to be developed and implemented into products.

You’re Still Vulnerable
Even with authentication, dynamic encryptions, and all of those fancy enterprise-grade features being implemented, users are still going to be vulnerable to Firesheep and MiTM attacks when accessing Internet-based content.

Other methods for capturing traffic and executing MiTM attacks still exist. Some example scenarios include:
  • Disgruntled ISP employee capturing your home / corporate Internet traffic
  • Evil twin hotspot networks, presenting a certificate that looks valid
  • Hacked hotspots that may have been broken into and are storing / sending data to a hacker
Let me put it this way, even if a Wi-Fi hotspot were encrypted, would you trust banking transactions over that network without the bank employing any application security using SSL? Probably not.

The only way to defeat these attacks is to ensure end-to-end data privacy and integrity between mutually authenticated systems. That means either host-based VPNs or application security.


Mitigating Firesheep for Good
The ultimate answer to Firesheep is for service and content providers to apply appropriate application security that provides end-to-end SSL/TLS session encryption.

This allows current, mature protocols which have already solved these problems to do what they were designed to do. Why go to the length of architecting and designing completely new solutions as described (in length) above, when solutions already exist and those solutions are easy to implement without negatively impacting performance?

Conclusions
Saying that open Wi-Fi networks is the crux of the problem is simply not true. Pointing the finger at open Wi-Fi hotspots is a way to provide an easy scapegoat for sensationalist media reporting.

Let’s stop ‘crying wolf’ over open Wi-Fi networks, they’re not the root issue, and forcing hotspot encryption down everyone’s throats will undermine usability at a tremendous cost to the public good. That tradeoff, as solution options stand today, is not worth it in my opinion. Let’s not cut off our thumb to spite our hand! We will do more harm by destroying the use of public Wi-Fi through the forced use of an unfriendly system than would occur by leaving it the way it is today.

Open Wi-Fi is here to stay, for a while, until the 802.11u amendment is finalized and implemented in commercially shipping products. 802.11u will enable an authenticated Wi-Fi hotspot that maintains consumer usability. Until that happens, open Wi-Fi will continue to be required.

Ultimately, content and service providers need to implement security properly instead of making poor decisions around the privacy of consumers’ data. Placing responsibility and accountability on content providers will make them more diligent in their approach.

In the case of Firesheep and sidejacking, that means SSL end-to-end for the life of the session. That’s the only real fix. And it’s at-least 3 years late in coming. Shame on the content and service providers for ignoring the issue this long!

Cheers,
-Andrew