In light of the recent hoo-rah about the Firesheep plugin, I’ve been reconsidering my approach to site security.
On a wireless lan (or a lan that still uses hubs, rather than switches, if any still exist) if you browse many popular web sites, you can’t trust your neighbor on the lan to not be sniffing your traffic. Firesheep demonstrates that problem quite adaquately!
But who is to say you can trust a centralized service either? Can you trust your trust group, on facebook? NO! Not currently. You’ve shared all that information with a central entity with MILLIONS of users and tens of thousands of customers - that (most likely) doesn’t have your best interests in mind. I think that is MUCH worse that your geeky neighbor in a coffee shop sniffing your traffic.
The way to fix the firesheep problem is to secure the web - first - by using end to end encryption - and the second, is to limit your trust group to only people and organizations you can actually trust.
The big disadvantage to crypto is economic:
Big fat servers in the cloud slow down a LOT when the transaction is encrypted. Using p2p crypto drives up the costs in the cloud. It also annoys the NSA, and everybody else that wants to be a man in the middle - google, facebook, twitter - etc.
On my bad days I look at the modern “highly personalized” web as one massive man in the middle attack, actually, by everybody that wants something out of you (which is just about everybody offering a “free” service). I applaud Doc Searls’s VRM efforts for this reason (but while he flies at 40,000 feet, I’m working at ground level trying to make the darn concepts work).
Peer to peer applications using IPv6 have a lot of potential to mitigate this problem, but so long as we have really insecure OS’s like windows lying around, and users that have no concept of security or an easily implementable trust model, going PTP may introduce more problems than it solves.
Still, once you exit the cloud, your privacy options become more robust. If you are running your own web server for your content, you generally have a LOT more cpu available for cryptography. The open-rd I use has a built in (and under-supported, sadly) crypto engine that might help.
In my case I use several external applications that make my life a little more secure. For chat - now that facebook supports jabber - I use pidgin or emacs + bitlbee (version 3.0 just released!) with the otr cryptographic extension. It’s good stuff, bitlbee especially lets me move all my chat accounts into one system, so I can run one application to chat, and one application only.
I run irc over a SSL connection, too. I even run my own jabber server. Conversations within my household never leave it. You can’t get much more secure than that, but there are still plenty of other places where personal information can leak.
My laptop has a secure directory for my passwords. I just started using myopenid, I’m not particularly fond of outsourcing that idea right now, but haven’t looked into how to run my own open-id server (yet!).
My email used to come directly to my laptop, over IPv6, over a secure link. I haven’t gotten around to re-implementing that, but I will soon.
On the web, I try to be careful. I change my passwords frequently, and try NEVER to log into an important service from a public terminal. (keyloggers are far more scary, and common, than stuff like firesheep) It bothers me a lot that skype’s security model is kind of unknown.
I’ve decided I’ll make this blog and wiki use https throughout, by default, for editing, at least. For everything, if I can swing it. I have plenty of spare cpu for cryptography throughout the system, now that I’ve got rid of the dynamicism and database dependence of a conventional design. I think.
Years ago John Gilmore started the Freeswan project with the express goal of securing 5% of internet traffic in under 5 years. He failed - but vpns such as freeswan, strongswan, and derivatives are everywhere, and the idea of opportunistic encryption for ALL traffic remains doable - if enough people can agree on standards.
There are a few other old - and very secure - ideas, left unimplemented in modern days, that I may try also. The first is pgp for email, and perhaps other applications that need a trust group. The second is ssl browser certificates for login…