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?
Great job breaking down what is a fairly complex interaction, behind the scenes, and explaining it with an analogy that everyone can easily understand. Well done…
-Gary
Fantastic way of describing the process!!! Breaks it down in Laymans terms thanks!!!
Very solid post. I saw a website with a post exactly identical to this one a couple of days ago. This post is a day older so I recon they have just copied and eddited it. I am not accusing you of copyright abuse it’s merely just warning that it’s. I can not recall the page, sorry (age thing)
Hi Cursus,
I’ve actually heard the analogy before a long time ago, which is why it stuck with me. But the content on this post is 100% content that I wrote from scratch.
Thank you very much for this explanation, that was awesome! I’ve finally understood how SSL works because of your post, thanks a million 🙂
Absolutely the best summary of SSL I’ve read, it makes things so much easier to understand. Thanks!
Can you explain, in the same awesome easy explanation with analogies, the need for ssl certificates and certifying authorities? Will be awaiting your post. I’m sure a lot are interested to understand too. Thanks!!!
Certificates and authorities relate to trust, while SSL in general relates to security. There are root certificate authorities (CAs) that are absolutely trusted – our computers know them to be trusted because our operating systems, such as Windows and Mac OS, ship with their certificates already installed on them. We’ll call those root certificates.
Now let’s say another company starts up, say GoDaddy, but they want to issue certificates themselves. Unfortunately nobody would trust a certificate issued by GoDaddy, since none of our computers have GoDaddy’s certificate installed. So what happens is GoDaddy asks one of the root certificate providers to verify GoDaddy is who they say they are, and then issue them a certificate that was signed by their root certificate.
Now, when we go to GoDaddy, we see their untrusted certificate, but we also notice that it has been issued by one of the root CAs, and using the certificate installed on our computer we verify that it was indeed issued by them (basically the certificate on my computer contains the root CA’s public key, and they sign the SSL certificate with their private key – since I can decode it using my public key, I basically know it was generated by them. It’s a simplification, but that’s basically how it works).
In this way, we form what is known as a certificate chain, which implies trust. Basically if a trusted element vouched for an untrusted one, we assume the untrusted one is now trusted.
Same as when you get your SSL certificate from GoDaddy. GoDaddy verifies your information and assigns you a SSL certificate signed by them. A browser pointed at your site will grab your certificate, see that it’s not a trusted root CA, realize that it was signed by GoDaddy, then grab GoDaddy’s cert, see that it’s not a trusted root CA, check who signed it, see that it’s a root CA, grab the appropriate certificate from the OS, and then verify it. In essence,the root CA vouched for GoDaddy and then GoDaddy vouched for you. That means we should trust you are who you say you are because everyone along the entire chain vouched for each other, all the way back to the root CA.
You can actually make a SSL certificate yourself and install it. These are known as self-signed certificates, and are routinely used in the testing phase. Because a certificate chain cannot be established, all browsers will report a security warning on the site which basically means the certificate chain did not go all the way back to a trusted element. In that case you’re basically not a trusted site, and people should be wary about who you are.
thank u very much for explaination. i understand very well what ssl stand for.thank’s a lot.
Great analogy (double-locking.) Great context (SSL and Certificates.) Thanks!
The package analogy was a great one; the key or combination is never sent through the mail, so only the sender or receiver can unlock any of the locks. I’m just a little confused by how the public key prevents the message from being eavesdropped on, though. If everyone in the whole world has the public key, doesn’t that mean that everyone in the whole world can unlock one of the locks? Your analogy says that the two people on each end of the package shipment are the only ones with keys, and each of those two people can unlock only one lock. But the public key suggests that one of the people shipped everyone in the whole world a key to one of the locks.
You also said that the private key can decode info encrypted with the public key, and the public key can decode info encrypted with the private key. That suggests that the keys to unlock the package have been swapped somehow, and furthermore, everyone in the whole world can unlock a package sent by one of the people. The double-lock scenario breaks down, because if the private guy sends a package, it could be intercepted by anyone in the whole world, who will be able to open it.
It might be helpful to understand how the handshake works, how the symmetric key is sent. I look at it like this. If private key guy sends the symmetric key, encrypting it, then anyone in the world can intercept and decode it, because they have the public key. Then they will be able to decode further data sent. But if public guy sends the symmetric key first, and someone intercepts it, they can’t decode it to find out what the symmetric key is, but if they replace it with their own symmetric key, public guy will send data (say, username and password) with his symmetric key and interceptor still won’t know what it is, but will be able to figure out what the server sends back?
I haven’t looked at this post in a while, but here’s how I think it works.
1) Party A generates a symmetric encryption key and puts it in the package
2) Party A then locks the package using Party B’s public key
3) Party A sends the package to Party B
4) Party B gets the package and puts a new lock on it using Party A’s public key
5) Party B sends the package back to Party A
6) Party A removes the lock put on in #4 using his own Private Key
7) Party A sends the package back to Party B
8) Party B removes the lock put on in #2 using his own Private Key
9) The symmetric key from #1 is retrieved and communications can begin using a symmetric cypher
The private key is the only thing that can decrypt a message using the public key, and it’s kept safe by both of the parties. The trick is that we’re using each other’s public keys to create our locks.
Nothing else I’ve read validates this dual lock scenario. I continue to see the below steps repeated in all other explanations.
* A public key encrypts.
* A private key decrypts.
1. Client requests SSL
2. Server sends types and versions available
3. Client chooses type and version to use
4. Server sends certificate (containing public key)
5. Client validates sender’s authenticity (lookup: certificate chains)
6. Client generates a symmetric key (lookup: Pre-Master Secret, Master Secret & Session Key)
7. Client encrypts the symmetric key using the Server’s public key and sends it.
7.5 [If requested] Client sends with it a certificate so that the server can validate authenticity (for p2p)
8. Server decrypts the symmetric key using the Server’s private key
Client & Server now use a symmetric key until the session ends.
I’m not suggesting you’re wrong; I’m confused. In my quest to figure this out I can’t find a second source for this dual-lock scenario. My layman’s knowledge of encryption also makes it hard to believe that you can scramble a message and then scramble it a second time in such a way that the first scrambling can be undone without further scrambling the second.
Is there a good technical document explaining the dual lock?
If these types of examples aren’t doing it for you, then I suggest you go through the ITU documentations that describe the protocol in detail.
Great analogy! Breaking it down in layman’s term. Keep it up.