How SSL Works

It's been a long time since I did a technology post, but I've recently had security on my mind and thought I would give a quick primer for SSL. For those of you who don't know, SSL stands for secure socket layer, and is the technology on the internet that makes all eCommerce and web security possible. And here's how it works.

First, you need to understand the two different types of encryption.

Symmetric Encryption

Symmetric encryption is any encryption that involves one key and can be decoded in exactly the same manner that it was encoded. In fact, often decoding a message is simply the result of encoding an already encoded message, which produces the original plain text.

For example, one could simply replace the letter "e" with the letter "i" in a document (and vice versa) and send it to a friend. Obviously it's a pretty crappy form of encryption, but the result would be symmetric. If your friend applied the same algorithm when he or she received the message, the original plain text would be decoded and they could read the message.

Symmetric encryption is extremely fast, but it requires both parties have access to the encryption key (often a passphrase) before hand. If it's a shared secret, then it works well. But if someone needs to get that key to a friend, then the question becomes how does one get an encryption passphrase to someone else without compromising the original message? More on this in a sec.

Asymmetric Encryption - Also Known As Private/Public Key

Asymmetric Encryption involves mathematical algorithms that are easy to compute in the forward direction, but nearly impossible to compute in the reverse direction. As a result, they are nearly impossible to crack using computers, not unless you have huge mainframes at your disposal. The entire security infrastructure of most governments are based on these encryption algorithms, some of which are called DES, NSA, RSA, etc.

Public key / private key encryption is named because it requires two keys instead of one as in the symmetric case. The private key is generated first, and the public key is derived mathematically from the private key. As their names indicate, the private key *must* be kept private at all times, but it is safe to give out the public key to others (assuming you want them to be able to read your encrypted messages).

Mathematically, the person with the private key can decode any message encrypted using the public key, and any person with the public key can decrypt a message that was encrypted with the private key.

One typical usage of private/public key cryptography is in verifying identities. For example, if I create a public key / private key pair and post my public key online somewhere (for example on duanestorey.com), it then stands to reason that if you can decrypt an encrypted message of mine using my public key that the message must have been generated using my private key, and therefore must have been generated by me. That type of signature authentication forms the basis for most signature algorithms in email software (it's slightly more complicated, because then the issue of Trust comes into play - yes you can verify that the person who owns duanestorey.com was the same person who created that message, but at that point you don't know for certain that it's *the* Duane Storey, as in me).

Symmetric encryption is actually very fast to perform, but since it only uses one key, it's not as secure as asymmetric encryption. Likewise, asymmetric encryption is slow computationally, but it's far more secure. More on these traits shortly.

How To Send A Secure Message Down An Insecure Channel?

That's the million dollar (probably trillion dollar question) that has been answered by SSL. We know that the internet without SSL is insecure, since packets are routed all over the place in plain, decrypted form. So how we can start a secure session knowing that the medium is insecure? Well, it actually takes a pretty cool algorithm that uses both symmetric and asymmetric encryption.

I'm going to give an example that isn't based on the Internet, since I think it'll make things far more clear. Let's say, for example, that I needed to mail my business partner, Dale, a package, but needed to guarantee that nobody could get at the contents except for him.

One option is to put a combination lock on the package, and then mail it that way. That's a good idea, but it still doesn't solve the problem with how to get Dale the combination. If he already has it written down somewhere at home, then we're golden. But I know for a fact he doesn't have it, so I need to do something else. Sure, I could call Dale up on the phone, but if it's a really important package, then it's possible someone is listening to my phone and will intercept the combination. Once they have that, they can simply intercept the package and steal the contents. In security speak this type of attack is known as a Man In The Middle attack, since it involves a third party intercepting information that compromises the message.

Another option would be to purchase a lock and key, and then mail the package to Dale with the lock on it. But then I have to find a way to get the key to Dale, and unfortunately my only option is to also mail that to Dale. There's less chance someone will intercept the message if I mail it another way perhaps, but it's still not a 100% secure idea. If I were to do that, it would be a form of Security By Obscurity - I've made deciphering the message more difficult, but not impossible for someone committed to the task.

So how can I get the package to Dale in such a way that I don't have to mail him a key down an insecure channel (the mail) and also don't require Dale to have foreknowledge of a combination (or a passphrase) to open (i.e. decrypt) the message?

Here's how.

I take the package that I'm going to send Dale and I put a lock on it. It doesn't matter what type of lock, and it doesn't matter if it's a combination or a key. Once I put a lock on it, I take it down to the post office and I mail it to Dale. Let's assume for an instance that there are no bolt cutters around that can break my lock, so as the package makes its way across the country it's 100% secure.

Now Dale goes down to the post office and gets the package. Unfortunately he sees a big lock on it and realizes he has no idea what the combination is. He knows he can't call me to find out, since our phones are being tapped. So he does the only thing he can think of - he puts another lock on it, this time one that only he knows the combination for. At that point he mails it back to me.

So once again, the package makes its way across the country, this time as a package with two completely independent locks on it, and is still a completely secure package. As soon as it arrives I take it home and immediately notice there are two locks on it. At that point, since Dale's lock is still firmly in place, it's completely ok for me to remove my own lock, since I know the combination and the package will remain secure after my lock is gone. So that's what I do. Now we have a package with one lock on it: Dale's. So I mail it back across the country, Dale receives it, and can now remove the lock and access the contents inside. At all times the package was traveling with at least one lock on it, and part of the time with two, so it was always secure.

SSL and Internet Security

That's how SSL works. Every time you open a browser and point it to an address with https:// in the address bar, that same package/lock scenario is going on in the form of a handshake. In the case of the internet though, the locks are two independent private key / public key algorithms, one locally and one remotely, and the contents of the package are a randomly generated symmetric encryption key that both parties can use once the handshake is over.

Since asymmetric encryption is slow, the package exchange with the locks only happens once during the handshake. Once the package (i.e. the handshake) is received (i.e. completed) and the locks (i.e. the public/private key encryption) are removed, both parties are left with a symmetric encryption key that can be used for all subsequent communications. So basically you're using asymmetric encryption keys to securely pass a symmetric encryption key down an insecure channel, after which point you can communicate using symmetrically encrypted data, and the channel is secure.

Pretty cool, huh?