SSL and websites requiring you to log in

The scene

You walk into your favorite coffee shop–laptop/smartphone/tablet all in tow–you set up camp at a table, order your favorite coffee (and maybe an apple fritter…mmmmmm), spread your work all over the table (so you at least give the impression of being busy…what, I’m the only one who does that?), and connect your

Image from

Mark Feuerstein sees you using an unsecured wireless network without using SSL.

electronic device to the unsecured wireless network that the coffee shop so generously and freely (literally) gives its customers.

This is all well and good (and very considerate of the coffee shops out there!), but thanks to the negligence of most of the websites you use, this puts a lot of your personal information at risk. Yes, we’ve always heard about not transmitting your credit card number over wireless, but there’s a lot more to it than that, and you should understand how all this stuff works so you can be reasonably sure how your data is being transmitted, be it messages over Facebook or emails over Gmail.

A primer in data transfer protocols

First, a little background as to what happens when you direct your web browser to, say, Facebook. I’ll skip as many of the low-level technical details as I can (the bottom three layers in the figure) and keep this as relevant as possible to the issue of making sure your personal information stays personal, but be aware that if you went deeper there are additional methods of securing your connections. Image from

Simply speaking, when you hit enter after typing “”, your browser asks your operating system to effectively start at the very bottom of the OSI Model you see on the right. The actual data you and Facebook send back and forth doesn’t appear until the very top layer, Application. The layer before that, Presentation, is where SSL sits.

So when you log into Facebook, upon hitting the 6th layer, SSL kicks in and encrypts the 7th layer (which contains your login information) to protect it from prying eyes. Once you’ve logged in, you’re no longer susceptible to login attacks and free to roam Facebook without SSL. Right?

Mmmmmm no.

Packet sniffing is a drug, or winning

Packet sniffing is one of the most elegant and simple ways to see what’s going on in a network. The fact is, if you’re on a wireless network, chances are there are several others on the same network (unless it’s your home network and you’ve password-protected it, which will actually encrypt your data from much further down the OSI model), which means your collective information is being sent over the same pipes.

Imagine several groups of people using the same room for their meeting. It’s not very difficult to simply listen in to the other groups’ conversations. Unless each group was speaking in code (which is what an encrypted wireless network will do), it’s very possible and very easy for everyone to eavesdrop each other.

Try Wireshark. Try Kismet. You could even go hardcore and just run tcpdump. Point is, it’s not remotely difficult for a relatively untrained laptop user to download a free tool, set up camp at StarBucks, and be reading all the web traffic of everyone in the coffee shop.

SSL to the rescue! …sometimes.

SSL will solve these issues, at least in theory. Since SSL works at the 6th layer, it will encrypt all your data in the 7th and keep it safely garbled and unreadable from the prying eyes of script kiddies looking for a free Facebook account to plunder.

Image from

Script kiddie got pwn3d.

Here’s the problem: about 90% of websites out there will enforce SSL when you’re logging in, but once you’ve done that, they drop the SSL and let you browse your account unencrypted (unless you change your password, or payment options, or something like that).

Why does this happen?

Well, one could argue that when you’re browsing your News Feed, who really cares if someone is reading. And if you’re uploading photos, who cares if someone is watching. Granted I think most of you would be disturbed by those thoughts (I am), but for the sake of brainstorming this could be one argument. After all, SSL is encryption, and encryption is not computationally cheap.

But what would site-wide SSL do? One word: cookies.

The curse of HTTP cookies

You know how, when you’re logging into a site, there’s usually a little checkbox that says “Remember me”? What this does is, once you’ve successfully logged in, the site will have your browser create a tiny little text file on your machine called a “cookie” that will contain some encrypted information that, somehow, uniquely identifies “you” on their site. This way, when you come back, the site will ask your browser to find a cookie specific to their site and, if it exists and contains correct information, will allow you to bypass logging in again and go straight to poking people.

Image from’s the problem: that cookie has to be passed to the Facebook server every time you click a link, view a profile page, click on a photo, or any other activity within Facebook. This cookie uniquely identifies you, and yet it’s being sent over the wire without encryption. All someone would have to do, then, is capture the cookie as it’s being sent, install it into their own browser (rather quickly, since servers do tend to update cookies very quickly to avoid this sort of thing), and voila, this person is now browsing around Facebook as you, and didn’t even have to be bothered to log in!

How hard is this to do, you ask? Let me introduce you to a little tool called Firesheep

Firesheep the messenger

Firesheep was designed with one goal in mind: point out to companies who run big, busy websites how vitally important it was to encrypt absolutely everything in SSL. Here’s how it works:

  1. User installs Firesheep into Firefox as an extension.
  2. User sets up shop on an open wireless network.
  3. User clicks the “Capture” button in Firesheep.
  4. Depending on the traffic of the network, every time an unencrypted cookie flies through the air, Firesheep automatically grabs the cookie and provides a link to the User to click and automatically log into that account–Facebook, Gmail, Twitter, Amazon, and many, many others–instantly.

That’s it. Seriously. It’s that easy. In fact, at a conference I attended (I won’t say which one, but let’s just say there were a lot of extremely tech-savvy folks present), the wireless network was unrestricted so I decided to give Firesheep a try.

You won’t believe what I got:

Yes, every single row is an account I could have hijacked.

Obviously I blurred out the avatars, excepting the icons that identified the sites they belonged to. But those were all accounts I could have hijacked. On my honor as a fledgling scientist and tech geek, I did not hijack a single one (in fact, the list contained a few of my own accounts, too) and deleted the data immediately after taking this screenshot. But it’s stark proof as to how incredibly easy it is to grab someone’s information.

You can probably guess that Firesheep’s author has come under a lot of fire for putting out such a tool, but if you read his site, you’ll see that the sole reason he wrote this plugin was to make painfully obvious the serious flaws in user security of some of the biggest and busiest websites. The simple fact is, lots of other people have been using this exact technique for quite awhile now, they just haven’t made that knowledge public. Now it is, and the major sites have already begun rolling out perpetual SSL.

So, what now?

I should stress: open wireless networks are great (obligatory XKCD), just make sure you know how to adequately protect your information if you decide to use one. If you’re on an open wireless network, use SSL. All the freaking time. If there’s a login, use SSL. If you logged in once before and are now using cookies to bypass it, use SSL the whole time. If the site doesn’t allow you to use SSL all the time, download a plugin to do it (Firefox has HTTPS Everywhere, for example).

If you simply can’t enforce SSL, and don’t have access to an encrypted or wired network, there are still options but they get a little fancy. My favorite is the SOCKS proxy approach: fire up a terminal, create an encrypted tunnel to a server somewhere (the command ssh -C -D 8888 will work perfectly), then modify your browser options to use a SOCKS proxy through port 8888 of your local machine, and voila, your web traffic is wholly encrypted from layer 5 on up, precluding the need for SSL at all. VPNs work in a similar fashion (a SOCKS proxy is a sort of poor man’s VPN), and if you really wanted to get fancy you could hit up the Tor project.

Failing all these, you simply save your data to your machine before you leave your house, and don’t turn on your wireless again until you’re in an encrypted network or back home.

By protecting your identity online, you can be more like this lolcat:


About Shannon Quinn

Oh hai!
This entry was posted in Internet, lolcat, Programming, Real Life, Technology and tagged , , , , , , , , , , , , , , , , , , , , , , , , , , , , , . Bookmark the permalink.

Leave a Reply

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

You are commenting using your 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