How SSL works

How can we exchange information securely on the Internet?

Let's say that Mary wants to exchange information with BigSecureBank.com. It will give Mary a key and she will encrypt the information with that key. Then, BigSecureBank.com decrypts the information with the same key. So the trick is, how do you get the key from BigSecureBank.com without anyone else seeing it?

The Big Problem

If you are connected by a wired or wireless network, the information still passes through your ISP and a number of other computers on its way to the bank. If you are connected at a motel or Internet cafe, you have no idea who could be listening in and watching your traffic. So, how does the bank give you a key which no one else can see, when someone else could be watching everything?

What if there is someone between you and BigSecureBank.com? Someone who is watching everything you send and everything they send. That person will be able to get the key that you are sent and use it to decrypt everything. This is called the "Man in the Middle" problem.

This is the problem which SSL solves.

The Solution

The big concept we must understand is Public and Private keys. Cryptologists figured out how to create a cipher that allows you to encrypt stuff with one key and then decrypt it with another key. These are called, Asymmetric keys. It doesn't matter which is used. If Part A of the key encrypts then Part B will decrypt. If Part B encrypts then Part A will decrypt. This solves the problem. Part A of the key is kept private. BigSecureBank.com locks it up and keeps it safe. Part B is made public. So, Part A is called the Private Key. Part B is called the Public key.  Now, if you encrypt a message with the Public key of BigSecureBank.com then only BigSecureBank.com can decrypt it, because only BigSecureBank.com has the matching private key.

The bank or Web store goes to a special company called a Certificate Authority. They purchase a special SSL certificate from them. The certificate authority verifies that the people buying the key really represent the store or bank and that they own the website in question. The Certificate authority then embeds the Public Key in a tamper proof certificate showing that this website is really owned by the bank or store. Now, if that Public key is used to encrypt something, then only the owner of the certificate can decrypt it. When you go to a website which sets up an SSL or secure connection, your browser verifies that the website has a legitimate certificate for that exact site and it comes from a trusted Certificate Authority.

These Asymmetric keys are only used for agreeing on a symmetric key. The private key holder sends you part of the key. Your program then makes up the rest of the key. It sends him the other part of the key using his public key. Now you have the full key consisting of the part he sent and the part you make up. Only the intended receiver can decrypt the second part of the key, because only he has the private key. Then, he has the full key. Now you can both encrypt information and even if someone were in the middle watching everything you send and receive, they will never be able to get the key and decrypt your messages.

That is how you and your bank (or anyone else with an SSL connection) can agree on a password key with the world watching, but without anyone else being able to see what you have agreed upon.

What if someone tampers with the message?

What if someone could change the message? This would lead to lots of problems, so before you send the message, your program makes a digital fingerprint of the message and includes that in the encrypted package. When either Mary or BigSecureBank.com gets a message it has 2 parts:

1. The message and 2. The message's digital Fingerprint

If the message was tampered with, then the fingerprint won't be right. This makes the message tamper proof.

How Do We Know it is really BigSecureBank.com?

Everything we've discussed above works almost flawlessly. It is very sound. Mary can be sure that she is communicating privately and with untampered messages with whoever she is connected to. Two possible issues remain, assuming your computer is not compromised: 1. Can you trust the Certificate Authority to do their job well? 2. Did your connection get hijacked so you have a legitimate certificate from someone else?

Conclusion

This system really works as long as you can trust the Certificate Authority or have some other way to verify the endpoint. If the Certificate authority is compromised, then the system breaks down. In the next issue I'll discuss the problems surrounding Certificate Authorities and offer some suggestions. In the next article I explain how OpenDns can be used to reduce the chance that your destination will be hijacked.