SSL and packet sniffing with Wireshark.

SSL stands for the secured socket layer and it is the way many websites handle encrypting your data as you communicate to them and helping you to verify that they are who you think they are, making it more difficult for others to view your traffic. Sites using SSL are often indicated by an https (note the “s”) at the beginning of the link. SSL works by having a group of certificate issuers who issue certificates indicating that there is a level of trust associated with a particular website, using this to verify that a website is who they are purporting to be, and then using standard encryption to communicate between the client, your computer, and the server, the website.

As simple as using SSL is, many services don’t use it. What happens then? Well if an eavesdropper,  let’s call her Eve, is somewhere on the same network as you are, for example if you are at a coffee house and she is sitting a few tables down from you, she can run any number of  freely available tools (or one she wrote herself)  to observe your network traffic. Being able to observe your network traffic is a problem if your traffic contains sensitive information, say passwords, love emails (or in this day and age more likely IMs), or credit card numbers.

Sounds like a rather far fetched scenario, if you aren’t familiar with how easy it is to be Eve(il) if you so choose. Here’s an example before I implemented SSL in my iPhone app‘s communications (pre release, of course) of me sniffing packets on my own personal network using an open source tool called Wireshark that I downloaded and got setup to use within minutes:

You can see in the red circle that my access token is clearly visible in plain text (only a small portion of it is included here for obvious reasons). The most complicated thing I had to do was figured out which packet to look at which involved me observing the typical packet pattern through Wireshark upon login from my application. Once I knew what the packet I wanted to sniff looked like, honing in on it even in the noise of hundreds of other packets was easy. A malicious user with this access token in his or her hand could login as me on Facebook, potentially doing more damage with information obtained there.

In contrast, after implementing SSL, looking at the corresponding packet I can see the access token is now encrypted:

As Eve I’m powerless at this level though there quite probably are more advanced tricks¹ I could play were I willing to invest the time.

So how did I implement SSL? First I obtained an SSL certificate for my server. I went with RapidSSL based on its price point, positive recommendations of its customer service, and simplicity. I then followed the procedure on the website to generate a certificate request, and later downloaded the certificate and installed it on my server. Remarkably that was it, and after changing my relevant urls to https I was able to verify that indeed my requests were going over SSL via Wireshark.

^1. SSL is aging poorly, as was alluded to by my reference to “other tricks” and we can do even better at battling the Eve’s of the world. See Moxie’s post on what is next.