Why Firesheep’s Time Has Come

This is what it takes to effect change…Sharable Shortlink

At Noon on Sunday, October 24th, 2010, during the final day of the 12th annual Toorcon Security Conference held in San Diego, two Seattle, Washington-based hackers, Eric Butler and Ian Gallagher, brought web session hijacking to the masses with their release of “Firesheep” … and the world was changed forever.

In case you’ve been somewhere off the grid, and have somehow missed the news, Firesheep is an incredibly easy to use add-on for the Firefox web browser that, when invoked while connected to any open and unencrypted WiFi hotspot, lists every active web session being conducted by anyone sharing the hotspot, and allows a snooping user to hijack any other user’s online web session logon with a simple double-click of the mouse. The snooper, then logged on and impersonating the victim, can do anything the original logged on user/victim might do.

Firesheep’s creators will be the first to tell you that what it is doing is not rocket science. The hacking capability to do this has been known and freely available within the hacking community for many years while the security community has been screaming into deaf ears about the need to fix the easily remedied configuration problems that make this possible. But thanks to Firesheep, reports are now coming in of people seeing other people using Firesheep in public WiFi hotspot settings.

Foreseeably, we will soon be hearing reports — many reports — of all sorts of mischief befalling the accounts of innocent users after they logged onto their accounts from open and unencrypted WiFi hotspots. At that point the implications of these long-standing security issues will finally hit home… and loud end-user complaints will drive the long-awaited changes the security community has been seeking for years.

The ease and simplicity of using Firesheep has transformed web session hijacking from a mysterious command-line driven black art into something for the masses. This is huge.

To get some sense for just how huge this is, check out the current download count of Firesheep at its download page: http://github.com/codebutler/firesheep/downloads After half a minute, press your browser’s page refresh to see how many more copies were downloaded just while you were looking at that first count.

I said above “the world was changed forever” because I can’t see how it could remain the way it has been in the face of point-and-click web session hijacking.

What needs to change? … Exactly two things:

  • 1. WiFi hotspots must encrypt. Period. They can still remain free and open, but they must use WPA encryption to protect their users from casual eavesdropping. As I wrote in my previous blog posting, this is not difficult. The hotspot’s WPA password does not need to be secret in order for all of the hotspot’s users to be protected from casual passive eavesdropping by each other and any other outsiders. For example, Starbucks could simply adopt the password “starbucks” throughout their entire coffee shop chain and have it known to all users. Users get the benefit of knowing that their traffic is encrypted in return for the minor one time burden of entering the “starbucks” password when prompted by their computers.

    Is this perfect protection? No. Because robust endpoint authentication will always be missing from any public-access WiFi system, complex active “man in the middle” attacks can still be mounted, but simply switching to encrypted WPA protocol raises the attack bar very much higher with near zero effort. And, importantly, switching to WPA encryption can be done immediately to offer significant protection to ALL users of such encrypted hotspots, not only just those who might be targeted by Firesheep. It’s just the right thing to do, and it’s SO simple.

  • 2. The bigger change that must also be made is for all vendors of web services to switch their connections over to using the SSL/TLS protocol exclusively. Only inertia and laziness has prevented this from being done long ago. It is my hope that the appearance of a tool as popular and easy-to-use as Firesheep will provide the incentive that has been missing for so long. The mischief it will cause should cause end users to demand this enhanced security from their web service vendors.

    Even when a user is not in the process of logging on, they have a reasonable expectation that their interactions with a remote server will be relatively private, not literally broadcast to anyone with an antenna … like a passing Google mapping car. And when those interactions contain the user’s logged on state cookies, as they must for the user to be recognized as currently logged on, a user’s unencrypted session becomes readily hijackable and hackable, making the situation even worse.

Isn’t switching over to SSL/TLS difficult and expensive?

No. The belief that switching to using pure SSL/TLS is any burden was obsoleted years ago with the addition of SSL/TLS Session Resume. Session Resume allows a particular client and server to perform the high-overhead public key negotiation just once (which they always need to do during the secure SSL/TLS logon anyway) and to then reuse those negotiated credentials for all future SSL/TLS connections being made. Since the credential reuse duration is typically 24 hours, very little additional burden is placed upon either the client or the server as a consequence of using SSL/TLS pervasively across a web site … always and for everything.

ALWAYS Authenticated & Encrypted – It’s WAY past time.

The idea of using SSL/TLS pervasively has been growing slowly but has, until now, been slow to catch on due to inertia more than anything else. Various client-side add-ons, such as the Electronic Frontier Foundation’s (EFF) HTTPS-Everywhere add-on, or Force-TLS, attempt to induce the client to push for SSL/TLS from its end. And the emerging HTTP Strict Transport Security (HTTP-STS) extension would allow web sites to enforce their own intention to only accept secure connection from clients.

This is all good, but someone needs to light a fire under the WiFi hotspot providers and web service vendors to make this happen … which is precisely why I am so pleased that “Firesheep” has finally happened.

The ground has already been prepared for the move to pervasive authentication and encryption. Let’s hope that the user, press, and provider communities will become upset enough over the appearance of Firesheep that these long-awaited security changes will finally be made. If that could happen, the world wide web be a far better and more secure place to hang out and play.

Steve's Sig

This entry was posted in Uncategorized. Bookmark the permalink.

71 Responses to Why Firesheep’s Time Has Come

  1. Pingback: Unencrypted Access Needs To Die

  2. Yannick Warnier says:

    Let’s hope somebody light the fire like that with IPv6 :-)

    On the server side, implementing HTTPS is still a burden for little applications as far as I know, as you have to link one domain certificate with one IP. Or is there something to cover that now?

    • Jared Mehle says:

      First of all, I always enjoy your insight on topics like this, Steve. You raise so many very good points. I’m completely in agreement with you about using HTTPS all the time. It’s not a problem of overhead anymore, it’s a problem of finances and server configurations.

      For example:
      On a website I maintain, we use a third-party ad vendor called IndieClick. They provide us with some Javascript that inserts their ads my site. When one of my pages with their ads is requested via HTTPS, it hangs while trying to initiate the secure connection to the ad server. I’ve contacted the company about fixing this and they flat out refuse to enable HTTPS. They say that HTTPS isn’t really necessary for anything but a login page and not enough of the sites they put ads on warrant it. This frustrates me to no end that they won’t go spend the $100 for the certificate and spend a few minutes configuring their servers. This is a huge company making probably hundreds of times more than the cost of a certificate, yet they refuse. If the bigger guys won’t budge, it’s going to be quite the effort to get everyone else to move.

      Likely, it’ll take some company like Google to step in and offer some sort of free certificate signing service.

    • Matt Giuca says:

      “Let’s hope somebody light the fire like that with IPv6″
      No need to hope … the fuse is burning up fast.

  3. Neil Laubenthal says:

    Hi Steve . . .ran across a post about the Firesheep plugin today . . .some guy claimed that he was on a wifi network that required a password (meaning it’s encrypted) and still saw all of the connections other users were making with their userid/password. How would that work . . .since all users on an encrypted network have their own session key he shouldn’t have been able to see anything, right? Maybe it was a WEP network instead of WPA and WEP doesn’t use different session keys maybe?

    There’s also https-everywhere . . .which I believe you talked about on SN recently, I’ve installed it and haven’t had an issue.

    Another question . . .generally speaking do other apps that pass credentials back to a central server (Twitter clients for instance) usually use an encrypted or unencrypted connection? I’m sure it varies with the app. . .just wondering if your experience showed a preference for one or the other.

    Great post . . .but coming from the guy that does SN one can hardly expect anything else.

    • Steve Gibson says:

      Neil…

      You’re correct about WEP vs WPA. Only WPA provides inter-client isolation for encrypted traffic. Under WEP, once the key is known all packets in the air, from and to everyone, can be decrypted.

      The whole trouble with web apps arises because they use secure connections only briefly to protect the logon username and password exchange. Then they give the web browser a “session cookie” to authenticate the user’s logon for some period of time.

      Then, if they are doing the WRONG thing, they switch the user back to unencrypted mode and that cookie is sent in the clear, unencrypted. Since the cookie is what the remote server uses to identify the user’s previously authenticated logon, and since the web session is no longer secured, anyone who is sniffing the WiFi hotspot’s traffic is able to grab that cookie and simply use it to impersonate the logged on user. It’s truly trivial. It’s ALWAYS been possible … but it’s never been made so easy!

      /steve.

      • Neil Laubenthal says:

        So . . .I guess the TNO solution is to either use a VPN, only use hotspots that have WPA, use something like https-everywhere although that won’t help for non-browser apps and won’t help if the site doesn’t have ssl pages available, or just buy a MiFi from somebody and use it for all of your devices. I’m actually thinking seriously about one of those since it would provide a hotspot for both laptops as well as the iPads and iPhones (we’re a multi-device family) . . .the only real drawback is battery life on the MiFi but it’s just another thing to keep charged I guess, can’t get away from that these days.

        Seems like hotspots enabling WPA would be the easiest thing . . .but then they’ll get too many technical questions asking them for the password.

      • Mike Puchol says:

        Steve,

        WPA only isolates traffic on the air interface, but that’s it – an attacker can just as easily sniff traffic on a switched network unless traffic separation is strictly enforced. This can kill many enterprise and home networks of course, but at a public hotspot, you would rarely need host-to-host communications.

        It would be important that influentials move from simply suggesting the use of WPA/WPA2 as a solution, and moved onto:

        a) All sites to use SSL/TLS without exception.

        b) All commercial hotspot providers to block non-SSL access to well-known services, eg. Gmail.

        c) All users of public hotspots to use VPN services, be it corporate or paid – there are many providers now that offer yearly service for less than what most antivirus suites cost.

  4. Ronc says:

    This should have been included with Windows!

  5. Pingback: Beware of Firesheep! You may have already been hacked! | Just a Geek

  6. Latch says:

    The cost switching over to SSL includes the impact on transparent caching and accelerator services like Akamai. With those two largely disabled, a popular web server would have to process many times more requests than it needs to with non-secured HTTP.

    Secondly, not *everyone* needs SSL. There are lots and lots of completely public, read-only websites out there full of useful reference information. Even web 2.0 sites like Wikipedia service the vast majority of requests in anonymous mode. Why bother with encrypting that traffic? The only reason I can think of is that the guy sitting next to me in Starbucks may be able to see what Wikipedia page I am visiting, but I am personally fine with that. It is a public space after all and there really is no expectation of privacy.

    • Latch said, “The only reason I can think of is that the guy sitting next to me in Starbucks may be able to see what Wikipedia page I am visiting, but I am personally fine with that.”

      That’s not the point. The point is, to use your example, if you have a Wikipedia account and you’re logged into Wikipedia, Firesheep could potentially be used to steal your session. That means someone else could start defacing Wikipedia posing as you, and of course that could get your account permanently banned. If you use HTTPS-Everywhere, that should be sufficient to protect your Wikipedia session from being hijacked. However, when you’re using a public Wi-Fi hotspot, using a VPN to do all your browsing is a much better idea. People can still “shoulder surf” but that’s not what you’re trying to guard against.

      If anyone is still confused about this, I recommend listening to Steve’s podcast about Firesheep: https://www.grc.com/sn/sn-272.htm

    • Steve Gibson says:

      Latch…

      You certainly make some good points. However, the argument could be made and, I think, defended, that even transparent external third-party caching represents a privacy and security threat. And it’s not clear how valuable that is when client’s do their own local caching which will still be effective under the cloak of persistent SSL.

      As for accelerator services such as Akamai, they’re not transparent and could certainly continue operating over HTTP without encryption. Our web browsers would/will need to become smarter about presenting those of-dubious-value-anyway “mixed content” warnings where some web page assets are SSL and others aren’t. For example… the notification ought to ONLY be made for mixtures within the same domain. That would allow the site’s assets to all be SSL, while third-party assets could remain just HTTP.

      Or… perhaps better… allow a reply header over SSL — like the HTTP-STS header — to ask the browser to suppress mixed-content warnings for that page. That would allow a site to deliberately use non-SSL for the page’s other assets, allowing for transparent 3rd-party caching, Akamai, etc. … while *still* protecting the user’s cookies from snooping — by marking the session cookies as “secure=”yes”” they would not be sent out with the non-SSL asset fetches.

      And, of course you’re right that not everyone needs SSL. I never meant to imply otherwise, and I doubt that people are generally confused about that. It’s only important in situations where stateful logon credentials are being provided in page-request headers. :)

      /Steve.

  7. James Bourne says:

    Won’t countries such as India, UAE etc start banning websites that change over to using SSL throughout?

  8. Jays says:

    Well said Steve! My sentiments reflected exactly! This has been way too long coming, and this is just the tool to provide that extra bit of incentive.

    If the crazed social networking sites like Facebook and Twitter can adopt this, we’ll be able to slowly move everyone on board to the idea (and expectation) of HTTP(S) being the standard!

  9. Pingback: Leuks op internet deze week- TinoKremer.nl

  10. Clayton Smith says:

    Steve, are you sure that WPA-PSK will stop passive sniffing? As far as I know, airdecap-ng (http://www.aircrack-ng.org/doku.php?id=airdecap-ng) can decrypt WPA-PSK traffic given the shared password, as long as the initial handshake is captured.

  11. Steve Gibson says:

    Clayton…

    You’re absolutely right for a single targeted user, but not for an entire network at once as in the same way that Firesheep operates now. My intent was to hugely raise the bar of difficulty for an attacker at minimal hassle for hotspot users. Specifically…

    When you think about it, there must be an inherent weakness if everyone is using the same well known passphrase: An attacker inherently knows everything that both the access point and the connected clients know.

    In the case of the WPA with a commonly known passphrase, the so-called “Pairwise Master Key” (PMK) is created independently by both the Access Point and each of the clients by iteratively (4096 times) hashing the shared (publicly known) passphrase plus the equally well-known SSID of the network. So everyone is able to obtain the same Pairwise Master Key (PMK) separately. And so, too, of course, is an attacker. (It’s done 4096 times so that it takes a long time to do it if you’re trying to crack WPA by brute-force guessing passphrases since you need to go through all the work of creating a unique PMK for each possible passphrase. But of course, if everyone knows the passphrase, no brute force is required.)

    Then, at the start of a new client’s session with an access point, the access point first generates a random number (called the ANonce in the protocol) and sends it to the client.

    The client also generates a random number (called the SNonce for “station nonce”) which it combines with the ANonce it received from the Access Point along with some other stuff and the PMK to generate the Pairwise Transient Key (PTK). The client sends the SNonce it generated back to the Access Point, cryptographically signed by the PTK.

    Upon receiving the client’s signed SNonce, the Access Point does the same thing the client did to generate the identical PTK. Once it has the PTK, it verifies that the SNonce’s cryptographic signature is correct.

    At this point, both the Access Point and the newly connected client have arrived at and agreed upon the same pairwise transient key (PTK) which they’ll use to encrypt their own link’s traffic.

    The trouble here, of course, is that a third-party eavesdropper will also have all of the information necessary to create its own copy of the PTK. It will have been able to see the Access Point’s ANonce sent to the client, as well as the client’s signed (but not encrypted) SNonce being returned to the Access Point. From that, an eavesdropper will be able to generate the PTK and proceed to decrypt all of the traffic exchanged between that pair of endpoints.

    In this scenario the attacker needs to be listening from the beginning of the conversation between the Access Point and the client. But another thing that a bad guy entering the scene late can do is to “spray the room” with deauthentication packets, effectively disconnecting every user on the hotspot and forcing their WiFi stacks to re-authenticate and re-connect … thus making all of their initial connection handshake packets available for capture.

    (Sometimes I really wish that my hat weren’t so white, since it really would be fun just writing industrial strength versions of this fun stuff and playing with it. Even then, I would never interfere with anyone’s traffic… but just seeing it all work would be so cool!)

    So, yes… there certainly is bad stuff that an attacker can do on a WPA encrypted hotspot when the passphrase is known to all.

    /steve.

    • Richard says:

      Steve, do you have any insight into why the WPA designers did it that way, rather than using the well-known Diffie-Hellman Key Exchange algorithm to create a session key that an eavesdropper cannot acquire?

      IPSec’s IKE uses Diffie-Hellman in this way, and IPSec has a pretty similar set of objectives to WPA.

  12. jpt says:

    How do cell phone apps fit into this? For example, a Twitter app or Foursquare app? I assume the cell phone browser would be susceptible, but are the apps too?

  13. BlueRaja says:

    “When you think about it, there must be an inherent weakness if everyone is using the same well known passphrase: An attacker inherently knows everything that both the access point and the connected clients know.”

    Isn’t that true of public key crypto as well?

  14. Simon Zerafa says:

    Hi Steve,

    If you don’t already watch it then you need to check out the Hak5 show on Revision 3:

    http://www.hak5.org/

    They have covered the evil twin concept and even have hardware for sale to demonstrate it:

    http://www.hak5.org/store/wifi-pineapple-version-2

    Check out the older shows where this is covered in detail.

    Regards

    Simon

  15. CS says:

    I installed Firesheep today after listening to SN. I am not on a public wifi network, and am on an ethernet cable connected desktop without the necessary wifi harrdware. I just wanted to check the extension out. I very shortly thereafter received a credit card fraud email reporting a transaction at a travel agency in Greece. Being suspicious of any such email, I called the number on the back of the card, and there had indeed been a fraudulent transaction made and the account was closed. I am extremely careful online. I run No Script on all my Firefox installations and always use the same card with fraud protection for online purchases. I have no hard evidence that this fraud is linked to installing Firesheep, but the timing is suspiciously coincidental. Has there been any verification that this code is not itself a hijack in the wild?

  16. 4ce_tls says:

    Steve, thanks for the Firesheep episode of SN and this blog.
    1)Have a look at the Options>Advanced>HTTPS in NoScript. You enter sites like Twitter, Facebook, etc.
    From then on (for those sites) NoScript “forbids active web content unless it comes from a secure (https) connection.” Although HTTPS Everywhere from EFF is a handier addon, since it’s preconfigured, so you don’t have to do any typing.
    2)You can also force encryption for all the cookies set over https by sites you enter.
    Not all sites will work when using these 2 options in NoScript, but it’s a start, no?

  17. steve brown says:

    Steve,
    I am curious if mobile broadband services (ie cricket broadband, clear wireless broadband) are vulnerable to firesheep? From what i am able to see, they seem to operate very similar to hotspots.

    I doubt they encrypt any traffic between the cell tower and my pc. I know (cricket) does not require me to enter a password to login – I also know that they assign each client a 10.x.x.x address. So, is it possible that any any evryone logged into any cell tower in the network would be vulnerable at all times (except on sites that use SSL)??? Aren’t these networks just like a giant open wifi network?

    I asked cricket….They say they use encryption, and not to worry but, I am about to disconnect from all “wireless” devices. Can you research this and comment?

    Thanks,

    Steve

  18. Pingback: Firesheep // Train-A-Scope – Linking People and Technology – Steven Knight Training

  19. Edson Santos says:

    I arrived in Toronto and went to a Starbucks;
    Firesheep downloaded and installed;
    View->Sidebar->Firesheep and Start Capturing;
    Several Facebook and Twitter users (with pictures!) displayed in the Firesheep Sidebar.

    What is the best thing to do now?
    Ask to talk to SB manager?
    Look for the users (I have theirs pictures, so it is easy) and show them that I’m able to enter theirs account?

    Tks,
    Edson

  20. Mike K says:

    Steve can you please use this blog to help us make our devices more secure on a weekly basis? Tell us how to turn on security for Chrome, Firefox, Safari, and on iPhones and ipads and Androids since we also use those to browse the net. Your the BEST!

  21. Pingback: Firesheeple : Solo Technology

  22. Pingback: Can WPA Protect against Firesheep on Same Network? | Consultoria Informática

  23. Scurrie says:

    I’m also curious about apps on a mobile device. Does anyone know what protocol the Facebook app on iPhone/iPod/iPad uses? Could these sessions also be easily hijacked by Firesheep?
    -Scott

    • darrennie says:

      Scurrie,
      I ran Firesheep at my local library and watched the names pop up then logged into Facebook over same wifi with my 2nd Gen iPod Touch and never saw anything relating to my device. Don’t know if this normal for this or was something I wasn’t doing correct but my iPod was not seen from my computer. Hope this helps.

  24. Bob Mulholland says:

    I administer many public WiFi hotspots for public libraries so this topic is very important to me. On the one hand I want patrons to have the easiest experience getting connected since it doesn’t take much support to have an unencrypted WiFi connection. On the other hand I want to be able to protect patrons’ security and privacy when it’s feasible.

    Moving to WPA mean all patrons need to know the password. I’m sure we can create the signage and literature to support that. The next thing that comes to mind is should I switch from unencrypted to WPA2 instead of WPA. Would that create greater security benefits or would I just open myself up to the fact that some patrons’ WiFi devices won’t have WPA2 and are more likely to have WPA? Is that why WPA is recommended in the article?

    Any insights into this would be extremely helpful to the communities that I support.

    • Steve Gibson says:

      Hi Bob…

      Leo had the really terrific idea of disclosing the WPA password IN the hotspot’s SSID. So, for example, name the hotspot: County Library (password is “free”) so that when the new hotspot comes up in the list of available connections, it gives the password at the same time. I think that’s so clever.

      And, for our purposes, WPA is absolutely equivalent to WPA2. :)

      /Steve.

      • Charles says:

        Over the weekend (11/6/10) I changed our classroom wireless network’s SSID to include the password, using WPA2/Personal.
        We have been operating an open hotspot for eight years and have not seen a problem. Today, Monday, I hope to get feedback from our wireless users. I am not yet comfortable adding the password to the SSID.

        • Bob Mulholland says:

          Charles, could you provide feedback when you can? I’d like to see how your experience is in a public environment.

          • Charles says:

            One ‘guru’ thinks I’m foolish and further advises not to use wireless at all. Otherwise, wireless works fine.

            I think users see a list of open hotspots and use another that is less complex rather than my SSID Password combo.

      • Bob Mulholland says:

        Thanks, Steve. I appreciate the reply and tip about including the password in the SSID. I’ll sit down with our Library Director and see if this plan will work for our public library.

  25. Pingback: Webluke Cast EP 1 | Webluke.net

  26. Steve,

    Thanks for you cogent blog.

    Do you remember the “flurry” of legal notifications that broadly peaked in 1998, prior to the Y2k rollover? Basically these invoked “general duty” and “due diligence” clauses in job contracts of C-level executives in corporations the senders exchanged significant data with, or shared other dependencies with. I believe that the analogy invoked at the time was of a multiple car pile up on the highway, where each driver sued the fellow behind, who ran into him. In essence, “If we fail to deliver because you fail to deliver to us, we will sue you.”

    At the time it seemed that these letters were more of a distraction than a help, but I may have judged too early.

    Could similar letters from aware customers turn Firesheep’s impact into a one-two punch? Imagine handing a sleepy barista an envelope the next time you pick up your double mocha triple decker whatever, and saying, “Would you give this to your manager please?” Eventually, a certain fraction of these letters would drift upward in the corporation. It would not take long (especially if read along with blog postings like these) for a light in someone’s head at corporate headquarters that there is some sort of organized campaign, grass roots or “astroturf”, to get the company to turn on WPA2 at all of their free WiFi Hotspots, and that there is also an opportunity to do the right thing. Steve, they might even do the right thing.

    Hopefully a memo will be drafted, and perky cardboard signs with the company logo will be distributed in packets to all of the storefronts (imagine Starbucks going into full gear on this, worldwide) saying “We’re improving your security!” and giving the WPA password and some simple instructions.

    I imagine that these demand letters could look something like this.

    ===============
    Dear Manager,

    I have been your customer since **Month** of YYYY. Until recently, I often made use of your free wireless Internet service. Unfortunately, you have not chosen to enable the WPA wireless security feature already built-in to your wireless access point. This is despite the fact that this security comes at no cost and at the minimal, one time, inconvenience to customers like myself, of entering a simple password. It is as if you simply could not be bothered.

    Until you enable WPA, my visits to your establishment will be fewer and briefer. I’ll use the Internet elsewhere, where it is safer. If I determine that my use of the Internet was compromised while I was at your establishment, you’ll be hearing from my attorney.

    Sincerely,

    Jane Q. Customer

    ====================

    Thanks again for SpinRite, Security Now! and for all you give back to the community.

    Mark Frautschi

  27. One of a long list of reasons *why* people need to lock down their WiFi access points to a minimum of 802.11g (WPA). I’m sharing this link on LiveJournal, Dreamwidth and Facebook, but – and this is the frightening thing – I don’t think the people on my friends’ list are really paying attention.

  28. steve says:

    As a general rule….with the exception of us geeks…..
    People don’t know, And what is more scary is they don’t want to know. I really beleive that most people take a similar attitude about backups. They don’t, and won’t make them a priority – until they lose a bunch of data.

    Same thing here. They don’t know what risks they take by not informing themselves, Not doing windows updates, Regular malware scans, Virus Scans, Firewall testing, and general maintenance on their pc. In short – The vast majority of “regular jane” and “regular joe” type people, Really don’t want to know, or be bothered with this stuff.

    How long have experts been telling people to back up, not click email attachments, not tape passwords under keyboards, not use simple passwords, install windows or other patches immediately, not send personal data such as ssn & dob through un-encrypted e-mail – (something i refused to do when asked by my employer to do), not download software from sources we cannot confirm as reputable, That the vast majority of VOIP calls can be listened to, recorded, edited, and spliced without our knowledge or consent ……The list goes on, and on….

    In my view, we need to start designing curriculum to educate the masses at all levels. Making it required coursework in elementary, Junior, Senior high & a college graduation requirement.

    If not, collectively, and individually, we will be at the mercy of predatory forces.

    I have adopted the policy that any piece of data i place, or allow to be placed on my system – is displayed on my front lawn. So if there is some detail i want kept out of public view – I don’t EVER put in on a computer (and to the best of my ability, don’t allow anyone else to either)

    In today’s world, all kinds of companies, government agencies (state & local), and others are asking us to provide data about ourselves that they simply don’t have a need to collect. We must stand our ground and not give out voluntarily – things such as our annual income, ssn, dob etc.

    People may insist they need it, but MY DATA IS MINE! and I will make the people and organizations that i provide it to, justify their need for it, and hold them personally & directly responsible for it’s protection, and the consequenses of mis-handling, or not protecting any data i provide. If i am not certain that this can be done, with a fair degree of competency, then i WILL NOT PROVIDE ANY DATA – REGARDLESS OF HOW BEGNIGN!

    Some may say this attitude is “not realistic” I think it is. I think we just need to start standing up and being responsible for our education, our data, and who we give it to. If we stand our ground when pressed to provide information in certain situations – then we begin to stem the tide of identity theft. We are not as “sheep” or in this case, “firesheep”…Being burned by our own apathy and lazyness.

    Comments welcome.

  29. MikeK says:

    Zscaler Releases Blacksheep to Fight Firesheep

    http://www.pcmag.com/article2/0,2817,2372231,00.asp

  30. Pingback: Seize the Deal and SSL

  31. Jason Brady says:

    Steve, what about “Hole 196″ in WPA2? supposedly it would allow an attacker to listen in on the encrypted traffic between the client and the AP.

    originally found at : http://www.codinghorror.com/blog/2010/11/breaking-the-webs-cookie-jar.html#comments
    references: http://www.networkworld.com/community/node/64146#comment-256843
    http://www.airtightnetworks.com/WPA2-Hole196

  32. Giancarlo Boaron says:

    Hi Steve. I made some tests and here goes some reports:

    – I tested Firesheep in a WEP wireless network and it works just fine in a Windows XP box but not in a Windows Vista box. Do you know why it happens?

    – It gets my Facebook and Twitter sessions. When tested with my Yahoo ID, it just identifies this ID but it’s not possible to view my session when double clicked. I think it happens due to some “lucky” reason (some redirect reason, maybe?), because Yahoo is not using HTTPS.

    []s
    Giancarlo

  33. Mike Dolan says:

    Steve … great article and podcast on this subject.

    I tried out the plugin on my local area network and with the LAN and WPA segments tested you are correct that you would only capture your section of the network (i.e your own sessions) …. but what about if a program like Cain and Able was added …. providing the ARP spoof attack to the segment and creating the man in the middle attack …. this makes Firesheeop capture the targeted communication … only problem … some SSL communications are dropped due to certificate errors …. but for a smash and grab attack this may be a option.

    Tested on the following setup:
    Attack Box – Desktop on LAN Segment
    Victim Box- iTouch 3rd Gen with Twitter and Facebook apps … Access via WPA2 802.11 access

    Outcome …. capture account information for both Facebook and Twitter

    Still need to test with the Attack box as a Wifi node … but should work the same right ?
    Anyway …. just my thoughts on your topic …. listed my blog post on my test as well

    WPA / LAN protected from Firesheep spying ? Maybe not the case !!

    http://su.pr/2SvZoU

  34. Steve wrote:

    The belief that switching to using pure SSL/TLS is any burden was obsoleted years ago with the addition of SSL/TLS Session Resume.

    This makes it sound like SSL Session Resume was an afterthought, added on after years of poor SSL performance. But the reality is that Session Resume was a feature right from the very beginning. Even SSL2 had it. And sadly, to this very day, many web sites have disabled or crippled that feature out of a misguided fear that SSL/TLS session resumption is somehow a security vulnerability.

    Steve, I agree with you that performance is no longer a serious obstacle to SSL/TLS usage, but perhaps you’d like to take another stab at the reason why that is so.

  35. Your name has come up as a #preferred presenter for our technology conference here in Edmonton, Alberta, Canada for November 2011.
    I think sharing with this audience would fit right with your mission. Wasn’t sure how best to reach out to you. Hope this may be of some interest to you, because you are of great interest to our membership, The Canadian Information Processing Society.

  36. Pingback: Can WPA Protect against Firesheep on Same Network? | Wifi Walker

  37. Brian says:

    Hi Steve —

    Just wanted to comment on your OpenVPN how-to. Your’s is the first explanation of routing vs. bridging that I have actually been able to comprehend. Thanks for that!
    I’m all for universal use of SSL/TLS as well. Happy Holidays!

  38. Pingback: Encourage your favorite free wifi hotspots to protect you from Firesheep « Rob Kraft's Software Development Blog

  39. Christian Alexandrov says:

    Firesheep is a good tool, which came to help. As always, industry follows the path of least resistance, and do something only if absolutley necessary. This means the industry has to suffer damage above a sertain point, to make it, do something about it. Firesheep, in it’s first days inflicted HUGE amout of damage, allowing anyone to pose as you. The industry was embarrassed, to HUGE degree, by openly showing and proving to everyone hey, they do not do any security. Facebook, Google, and others certanly fixed this, but i’m annoyed by this lack of interest to do something, to prevent this from happening. Even now, not everyone did all as they should, many made some cut-and-paste patchwork to patch few holes, but still left vulnerable to Firesheep, to inflict more damage, if Firesheep is used in the proper moment.

  40. Kris Heimbuch says:

    Steve,
    I came across an Android version of Firesheep that works with WPA2. I have not tested this myself but there are tests shown on youtube. The name of the APP is called FaceNiff. The website is http://faceniff.ponury.net/.

  41. Christian Alexandrov says:

    Kris Heimbuch, The website link you post says: FaceNiff is an Android app that allows you to sniff and intercept web session profiles over the WiFi that your mobile is connected to.
    It is possible to hijack sessions only when WiFi is not using EAP, but it should work over any private networks (Open/WEP/WPA-PSK/WPA2-PSK)
    The claim that faceniff works under wpa and wpa 2 is not completley true. WEP, WPA PSK, WPA 2 PSK, are simple ways to encrypt traffic and they use one common key to authenticate all devices on the network, and in this case many devices can decrypt each other’s traffic, allowing Firesheep to work. WPA or WPA2 when Used inTKIP or Radius mode offers INDIVIDUAL and UNIQUE keys to each client on the network, creating perfect interclient isolation, by making so that each client can only decript it’s own traffic. This kills Firesheep, on every platform.

  42. Corrosion says:

    SSL dosn’t protect people from this tool….. Just get SSLStrip and your off..
    The FACT is people don’t understand that all these so-called security upgrades are still sub-par.
    Even if someone does everything you mentioned, firesheep with an extra free tool or too can still get all that information just as easily

  43. Christian Alexandrov says:

    @Corrosion

    At the server side, Firesheep made it clear, either you fix your security, or die. SSLStrip. is no longer the ultimate tool to use. All sites that matter somehow in anyway, no longer accept non https: queries and connections, and migrate towards adopting TLS 1.2 and STS, abandoning any previous SSL and TLS versions. The rest of websites that are clearly insignificant, have proven that they are insignificant, to all of us ,by ignoring the security matter.

    speaking of User side, small number of people are really security aware, and do something to protect themselves, i agree with you. This is why google chrome started with silent constant background updates. this is why now microsoft and mozilla will adopt this update policy for their browsers as well.

    The claim you made, that even all done right might give you easy access – this is not true, this part is either trolling, or shows that you do not really know all aspects of WPA and WPA2 security. If WPA or WPA2 is done properly, each authenticated client on the network, gets UNIQUE and INDIVIDUAL public encryption key pair with the access point. This by itself makes sure you cannot decrypt my traffic, and i cannot decrypt yours. This is called Inter Client Isolation.

  44. Mike says:

    I always use this when in public neworks: http://www.sunvpn.com/.It` a OpenVPN service that encrypts all your traffic. Firesheep can`t read your seesion if you encrypt the traffic.

  45. Mike says:

    I always use this when in public networks: http://www.sunvpn.com/ .It` a OpenVPN service that encrypts all your traffic. Firesheep can`t read your seesion if you encrypt the traffic.

  46. Pingback: Home Server Build part 4 – Remote Access | kdmurray.blog

  47. soniax says:

    I use http://www.superbvpn.com/vpn-uk to watch BBC and everything works great.

  48. mosaic tile says:

    I really like your wp template, wherever would you get a hold of it through?

  49. That is right thing to do. Nobody knows such details about Firesheep so please talk about it loud and clear. Great job, sir.

  50. Reveur says:

    Awesome blog my friend

  51. cnn news says:

    An outstanding share! I’ve just forwarded this
    onto a colleague who has been conducting a little research on
    this. And he actually bought me dinner due to the fact that I discovered it for him…
    lol. So allow me to reword this…. Thanks for the meal!!
    But yeah, thanks for spending time to discuss this matter here on
    your web site.

  52. vancedecker says:

    Thanks Steve! I was broke and sitting at Starbucks when I read your post, now I’ve got two credit cards and am staying at the W.

  53. There’s certainly a lot to know about this topic. I really like all the points you have made.

  54. Hi to every body, it’s my first visit of this blog; this blog contains remarkable and genuinely good material
    in support of readers.

  55. This website was… how do you say it? Relevant!! Finally I’ve found something that helped
    me. Appreciate it!

  56. This paragraph will assist the internet users for building up new weblog or even a blog from start to end.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s