[kwlug-disc] Firesheep: Open WiFi cookie stealing for the masses ...
ldpaniak at fourpisolutions.com
Tue Oct 26 20:11:32 EDT 2010
On Tue, 2010-10-26 at 19:27 -0400, Khalid Baheyeldin wrote:
> On Tue, Oct 26, 2010 at 7:02 PM, Lori Paniak
> <ldpaniak at fourpisolutions.com> wrote:
> On Tue, 2010-10-26 at 17:26 -0400, Chris Frey wrote:
> > On Tue, Oct 26, 2010 at 05:09:49PM -0400, Khalid Baheyeldin
> > > I am no expert on wireless encryption, but I think
> enabling WPA with a
> > > weak password is enough to protect against site login
> > Neither am I, unfortunately. Does WPA2 turn wireless
> behaviour into
> > a switch based network vs. a hub based network? i.e. If
> you can
> > still use tcpdump to see other people's network activity
> after you've
> > connected using the public password, then things haven't
> > much more secure.
> > - Chris
> Good question. Since I'm not an expert either, I did a quick
> look on
> the interwebs. The conclusion is that if you know the
> passphrase and you
> capture the initial handshake of a WPA session, then you have
> access to
> the entire communication stream. In a coffee-shop setting, I
> these conditions would be easy to fulfill.
> With a VPN link to an external (wired) server, it should be
> straightforward to have all traffic routed over the tunnel.
> Of course
> the network performance hit is often substantial.
> Really, the architecturally sound method of solving this
> problem is for web sites to use SSL for sensitive
> communications. I
> mean it's not like https is new tech. What have people been
> for? This?
> SSL requires that the site owner buys a certificate, which is an added
> expense and effort to configure. It also requires that it be updated
> manually every year. Yes, you can use self signed certificates, but
> major browsers complain with a really scary
> warning if you use those.
> The other issue is that SSL on the server eats up a bit more CPU for
> the encryption than plain text HTTP.
> And it is one of these things that if everyone did it, all is well. If
> a few major sites don't, then it is less than useful. Compare that to
> PGP keys for signing emails. Only a few people use them.
> Remember that HTTP is not the only traffic that you will do on a
> typical desktop, or smartphone. If you are on IRC, or using Instant
> Messaging (e.g. Jabber), then probably you are unencrypted too.
> A VPN solves all this in one swoop, for an added performance penalty
> (a little bit of CPU, plus the lag from/to the VPN) and perhaps added
> expense too (either setup your own, or pay for a service).
I disagree. This is a structural problem that needs to be solved on the
server end, not the client end. A little extra work and expense (less
than the price of hosting?) is much less work and expense than each and
every user stringing their own VPN proxy. Not to mention the users who
don't know what VPN means. Maybe sites like Facebook should use their
piles of cash to hire some people who know something about securing
websites (like 2bits!).
Additional motivation for major sites to get their SSL act together
would be boycotts of those that exchange credentials in clear text.
The VPN solution is not going to be effective for real-time
communications like VoIP or video (though there are other solutions
there). Additionally, browsing the internet through your home VPN server
is not particularly pleasant due to the <600kbps bottleneck on uploads
I don't see eavesdropping on conversations as being (as big) a problem
as stealing and spoofing ID. Having definite attribution is more
important than content.
Bottom line: VPN is a band-aid that does not solve the underlying
problem and just lets it get worse.
Enough editorializing - time for a practical question: how secure is the
kwlug site? How can it be improved? At what cost? (Sounds like a new
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 490 bytes
Desc: This is a digitally signed message part
More information about the kwlug-disc