News Analysis: Firesheep is not just an open WiFi problem, and it is up to the web application makers to fully fix the problem. But there are interesting ideas afoot for how to eliminate open WiFi networks altogether.
When I first heard about the
Firesheep credential sidejacking attack and resulting outpouring of information
and advice how to protect or fix open WiFi to avoid attacks on social
networking users, my first thought was "How has this become a WiFi problem?"
But that doesn't mean there isn't room for wireless innovation to help mitigate
the problem, in lieu of Web application vendors doing the right thing and fully
securing their data.
is the Firefox extension for Mac and Windows that makes it painfully easy to
sidejack a Web session, allowing an attacker to steal cookies from another
user's unencrypted Web traffic and gain access to the victim's profile and
account on various Websites and services that don't practice end-to-end, full
Even if the Web application SSL (Secure Sockets Layer) encrypts the victim's authentication login
process, if the application later switches back to unencrypted HTTP and uses a
cookie to maintain the session, Firesheep can capture the necessary
authentication information from that cookie.
Open WiFi networks are the
easiest avenue for potential exploit, and there is room for differentiation
from wireless vendors implementing technologies above and beyond the standard
to help mitigate the attack surface. The standards-based preshared key or
802.1x protocols will thwart the majority of casual and opportunistic attacks,
while WiFi-vendor-specific technologies like dynamic preshared-keying and wireless
client isolation should also have a positive effect.
IBM X-Force Research team also recently discussed
a new way to generate security on open WiFi networks, proposing to mimic Website
security on wireless networks. An AP (access point) presents a digital
certificate to wireless clients as they connect to the wireless network, and
that certificate is used to set up a secure tunnel between the AP and the
I reached out to some
enterprise WiFi vendors to get their perspective on the X-Force idea. I
talked to Matthew Gast, director of product management at Aerohive Networks,
and Jon Green, senior product manager for mobile security at Aruba Networks, to
see how feasible they thought the idea may be.
Both saw PKI (Public Key Infrastructure) and interoperability as the key stumbling
Gast noted that using
untrusted certificates would lead to error messages on end-users devices, and
ultimately would put too much decision making in the user's hands. But using
trusted certificates means that every common OS needs the same set of trusted
root certificates, and every company running a hotspot has to get a corporate
certificate. Then certificate revocation becomes an issue: when to do it and
how to know when it's been revoked.
Green saw merit in the idea,
but he stressed the importance of interoperability, citing the importance of
getting the IEEE or the WiFi Alliance involved. "A vendor can't put it out
there and have it be on only 10 percent of the world's hotspots," he said. "If
the client devices must be ready to deal with (the security) as well, it has to
be a standard."
Of course, Firesheep or
other sidejacking tools can also steal credentials passed over any shared,
unencrypted wired networks. And, as pointed out by Andrew Vonnag
encryption can still be bypassed and attacked through ARP Cache Poison and
Man-In-The-Middle attacks. According to Vonnagy, to be fully secure, the
encryption must be end to end, and it is incumbent upon the Web application
providers to deploy it and standardize use on it.
"Facebook's not using SSL when it sends its authentication credentials is a big problem," said Aruba's Green. "It's something they can fix if they choose to put in the
infrastructure to do it, but it's going to be expensive. But unless the users
are demanding it, saying they won't use the service unless this [full SSL] is there, I'm not sure how much difference it will make."