How Does SSL Work?

---

Every modern web browser has built into it a very sophisticated encryption system that allows secure "conversations" with webservers equipped with an SSL secure server (See endnote).

This is about to get pretty technical so I am simplifying it greatly. If you find your eyes glazing over, don't worry. The main message here is that SSL ensures an encrypted communication between the customer's web browser and the merchant's webserver. This produces both customer confidence and a very secure communication system. Use it!

But some of you want to know how it works, so here goes.

Keys and Identities

You remember the Decoder Ring you found in a cereal box when you were a kid? It consisted of a wheel with the alphabet on each of two rotating discs. If you someone sent you a message where the "key" is A=L, you'd set the A above the L, and then determine that B=M and C=N, etc. Modern cryptography uses a very complex algorithm or formula to encode messages using a key. Rather than A=L, the key will be very large number used to scramble the text. If you were to give the key to your friend, he would be able to decode the messages you encode with it and visa versa.

Two problems present themselves, however, when you don't have face-to-face contact with a trusted friend.

• Who is your friend and who is the evil hacker? The Internet is a anonymous place where people are not always whom they seem. If you've spent any time in chat rooms, you know that "Pixiebabe" just might be a middle-aged man in Toledo. How do you know that you're speaking to the real online store, or just a mimic of it? That's where a Digital Certificate comes in, to identify the store as authentic, verified by a trusted Third Party (called the Certificate Authority).
• In addition, on the Internet you can't physically hand over a key, and whatever key you send electronically could be intercepted by an evil hacker. Enter a complex technology called Public Key encryption.

Private Keys and Public Keys

The way SSL solves this problem is to have two keys: a private key (that you never disclose to anyone) and a public key (which you may distribute freely to the general public). This is how it works: You send your friend your public key and he uses it to send you an encrypted message that only you can decode when you use your private key. Your friend can only encode the message; he wouldn't be able to decode it, since he only has your public key, not your private key. Confused yet?

You may be, but your web browser can keep it straight, and comes with the ability to encode and decode messages sent to and from an SSL-secure webserver.

Getting to Know You

The merchant's in-house webserver (or the merchant's web hosting service) has a Digital Certificate or Digital ID that identifies it as the authentic owner of a certain domain name. The Digital Certificate contains the several pieces of information, including the merchant's public key, signed by the Certificate Authority (such as VeriSign).

The customer's web browser has built into it a list of recognized Certificate Authorities (such as VeriSign) and their unforgeable digital signatures, so it can verify if a merchant's Digital Certificate is valid or a forgery.

Now the customer's web browser and the merchant's website begin a getting-to-know-you exchange, kind of like fax machines squawking as they're getting in synch with each other. Here are some of the important steps in this mating ritual:

1. The customer's web browser requests a secure page, such as https://www.yourcompany/orderform.htm
2. The merchant's webserver responds by sending the customer's web browser the Digital Certificate containing all its information.
3. The customer's web browser checks to be sure that the Digital Certificate is valid, hasn't expired, and matches the Certificate's domain name and the list of digital signature of Certificate Authorities the web browser has on file. Then it replies by encrypting a message using the merchant's public key. In this message will be a unique Session Key generated by the web browser from a random number.
4. The merchant's webserver decodes the unique Session Key using the merchant's Private Key. Now both the customer and the merchant have the same unique Session Key. If you were an evil hacker listening in, you could hear both the messages from the webserver and the customer, but you couldn't decode the customer's message to the webserver, since you don't possess the merchant's Private Key. (I'm skipping over some other checks performed at this time.)
   
   Now the merchant's webserver uses the unique Session Key to encode a message to customer's webserver, and visa versa. The two are in step and the dance has begun, dancing to a tune that only they can hear. They can whisper sweet nothings to each other encoded with this unique Session Key, and no one can tell what they're saying.

So long as the evil hacker can't guess the unique Session Key, he can't decode the messages being passed back and forth. It is gobbldy-gook so far as he is concerned. Now the customer can give his credit card number safely and the web server can echo it back for verification without any chance of an evil hacker kidnapping it on the way by.

That's how SSL works. Actually that's the kindergarten version of an extremely complex subject. But I hope it's enough to give you some confidence in the process. It really works quite smoothly and securely.

Note: SSL stands for "Secure Sockets Layer." "Socket" is a technical term that refers to an application programming interface, or API, which is used to communicate between two computers. "Layer" refers to the level or layer of this communication between the computers.