Posts Tagged 'Encrypted'

July 8, 2009

Encrypted Hot Chocolate

Imagine this scene: you’re sitting at a local coffee shop, having a drink and browsing the web. While checking out your favorite news site you see an e-mail come in where someone is commenting on your blog post from that morning. This is odd because while you remember checking blogs, you don’t remember posting one. On investigating you find a blog post that you definitely did not create. As you look around wondering what is going on you should probably take a peek at the guy sitting in the comfy chair with his headphones on running a wireless sniffer to grab passwords out of the air.

How does this happen? The coffee shops I’ve seen all run open wireless access points. This is great for flexibility and serving the most people but if the Access Point is unencrypted it is quite possible to run an application which will listen to the wireless network and record packets. These packets can then be examined by a tool like the Wireshark application. Since the packets are not encrypted then things like username/password combos can be read in clear text from the packet.

Knowing what the problem is, how do we work around it? Since we cannot encrypt the wireless session, we’ll encrypt the data itself. One option would be to do a VPN from your laptop in the coffee shop to a location out in the world. This would channel all of your traffic out through this other system. It’s a good solution but it can be a bit technically complicated if you don’t have one already set up. If you’re really only concerned with encrypting your HTTP traffic you could use the PuTTy application to tunnel traffic via an encrypted session to a Unix server here at SoftLayer by using the OpenSSH ability to act as a SOCKS5 proxy.

When you define your connection in PuTTy you can go down to Connection > SSH > Tunnels and then place a port number, such as 8080, in the Source field. Select “Dynamic” and “Auto” then click the Add button. Connect to your Unix server here at SoftLayer. Next stop is the browser. The way I configure my browser for this is to go into Firefox > Tools > Options > Advanced > Network > Settings (under Connection). Select “Manual proxy configuration” and then in the field labeled SOCKS Host: put “127.0.0.1” and for the port use the port you specified above. Leave the type as “SOCKS v5”. Select OK and then in the URL bar type “about:config” which will let you do advanced configuration. In the filter field type in “network.proxy.socks_remote_dns”. Right click on it and select Toggle. This will mark it true.

Now if you pull up a website which will tell you the IP that you are coming from (such as http://whatismyip.com) you should see it report back the IP address of your server here at SoftLayer. This happens because Firefox has been told to use 127.0.0.1:8080 as its SOCKSv5 proxy and this traffic gets tunneled via the encrypted SSH session to your server at SoftLayer. The server here will do the DNS lookup (due to network.proxy.socks_remote_dns) and then send out the request. The response will be tunneled back to your browser.

You do have to remember to fire up the PuTTY session but this isn’t so hard since if you try and browse without it the browser tries to hit the SOCKSv5 proxy port specified and fails. Beyond that I’ve not run into any troubles using this trick.

And now I think I will head off for some hot chocolate myself.

Categories: 
June 19, 2009

Self Signed SSL

A customer called up concerned the other day after getting a dire looking warning in Firefox3 regarding a self-signed SSL certificate.

"The certificate is not trusted because it is self signed."

In that case, she was connecting to her Plesk Control Panel and she wondered if it was safe. I figured the explanation might make for a worthwhile blog entry, so here goes.

When you connect to an HTTPS website your browser and the server exchange certificate information which allows them to encrypt the communication session. The certificates can be signed in two ways: by a certificate authority or what is known as self-signed. Either case is just as good from an encryption point of view. Keys are exchanged and data gets encrypted.

So if they are equally good from an encryption point of view why would someone pay for a CA signed certificate? The answer to that comes from the second function of an SSL cert: identity.

A CA signed cert is considered superior because someone (the CA) has said "Yes, the people to whom we've sold this cert have convinced us they are who they say they are". This convincing is sometimes little more than presenting some money to the CA. What makes the browser trust a given CA? That would be its configured store of trusted root certificates. For example, in Firefox3, if you go to Options > Advanced > Encryption and select View Certificates you can see the pre-installed trusted certificates under the Authorities tab. Provided a certificate has a chain of signatures leading back to one of these Authorities then Firefox will accept that it is legitimately signed.

To make the browser completely happy a certificate has to pass the following tests:

1) Valid signature
2) The Common Name needs to match the hostname you're trying to hit
3) The certificate has to be within its valid time period

A self-signed cert can match all of those criteria, provided you configure the browser to accept it as an Authority certificate.

Back to the original question... is it safe to work with a certificate which your browser has flagged as problematic. The answer is yes, if the problem is expected, such as hitting the self-signed cert on a new Plesk installation. Where you should be concerned is if a certificate that SHOULD be good, such as your bank, is causing the browser to complain. In that case further investigation is definitely warranted. It could be just a glitch or misconfiguration. It could also be someone trying to impersonate the target site.

Until next time... go forth and encrypt everything!

Subscribe to encrypted