Introduction to SSL

So, say you want to buy a book on Amazon. You go on the website, pick the book you want, add it to your cart and proceed to check out. While checking out, Amazon asks you for your credit card information, you enter it and they tell you your item will be shipped soon.

You really really want to be sure that only Amazon got your data, though, because you trust them. Since your information travels through a hundred devices before reaching Amazon’s servers, and each of these devices can look at what you sent, how can you be sure that someone along the line won’t get your credit card data?

This is where SSL comes in. SSL is short for Secure Sockets Layer, which is basically a layer that ensures that only the recipient on the other end sees what you send and vice versa. But how does SSL work?

Basically, if both you and the server have a common secret (e.g. a password), there are ways to encrypt your communications so that only people with the password (hopefully just you two) will be able to read what you send. In this case, though, you don’t have a common password established, and you can’t do it over the internet because someone might be listening in. What can you do?

The way SSL deals with this issue is by using certificates. A certificate is basically the equivalent of a piece of paper saying “yes, this person is Amazon, I checked”, and this piece of paper is signed by another person you trust to have actually done a good job at checking.

So, Amazon goes to a certification authority (the third party), says “please sign here so I can show this to people and tell them you certify this is me”. Then Amazon gets the certificate, your browser has a way of recognising that the signature of the third party is valid, and you get the green padlock on your address bar.

Problems with this scenario

What happens if someone hijacks Amazon’s address and makes it point to their server? Then they could act like they’re Amazon (maybe even pass data back and forth so you wouldn’t notice) and intercept your info.

However, in order to do that, they would also need to obtain a certificate signature that verified that they are also amazon.com, which is rather hard to do, unless the third party is untrustworthy or somehow forced to sign the certificate. It might also be the case that the third party just doesn’t care enough to check.

Another problem is that this costs money, sometimes in the hundreds or thousands of dollars per year, and it is simply not very good sense to rely on a third party to secure your communications.

What can be done?

A simple, effective and very clever way to deal with this problem is what the people over at Carnegie Mellon University have done. Perspectives does not rely on a single third party to tell you whether or not they checked the owner of the site. They, instead, run their own servers that look at certificates and tell you how long they have been there. If the certificate that Amazon is presenting you with now has been seen by the server for three consecutive years, there’s a pretty good chance that you are on the correct site.

This is a very good solution in more than one ways. Firstly, we don’t need to do away with the current system. We can use both in a complementary way to decide whether we are on the correct site or not. Secondly, it does not require a large cost on people who want security by allowing people to put up their own certificates that haven’t been signed by a third party and actually verify that they belong to the right site.

Another big advantage of this method is that you can run your own Perspectives server (called a “notary”), if you don’t trust the default ones in Perspectives. With many people running notaries, the system becomes much, much more secure than the current, authority-based one.

You can run Perspectives right now as a Firefox extension. It’s really simple to install and use, and I hope it will be available for many other browsers soon.