The Secure Socket Layer, SSL for short, is a protocol by which many services that communicate over the Internet can do so in a secure fashion. Before we discuss how SSL works and what kinds of security it provides, let us first see what happens without SSL.
Life on the Internet without SSL !
Let us compare communications between computers on the Internet and communications between people over the telephone. Without SSL, your computer-to-computer communications suffer from the same security problems from which your telephone communications suffer:
Who are you talking to?
In a phone conversation, how can you be sure that the person who picks up the phone at the other end is really the person you are trying to call (especially if you have never spoken to them before)? What if your phone call was intercepted or re-routed, or what if someone else is answering your call recipient’s phone? There really is no way to be sure you have reached the right person, especially if they are actively trying to fool you.
As you are aware of from watching TV or reading, it is very easy to tap phone lines: the police and spies do this all the time to covertly gather information. It is not easy to detect if your lines are tapped. The same applies with communications over the Internet — how can you be sure that your communications are not being “tapped” and recorded? This is especially problematic in public wifi hotspots.
This results in two very real security issues for communications over the Internet: 1. knowing for sure that you are connecting to the right servers (i.e. those at your bank and not those at a hacker’s or phisher’s web site), and 2. knowing that your data is safe from prying eyes during transit to those computers. This is where SSL comes in.
Enter the Secure Socket Layer (SSL)
To solve these problems to a large degree, most Internet services support use of SSL as a mechanism for securing communications. To illustrate how SSL works, let us use another analogy.
Client wants to communicate with a company to send important information back and forth. Client wants to be 100% sure that s/he is communicating with this particular company and that no one can eavesdrop on or intercept the communications. How can she/he do this?
- Client sends a courier to the company’s address.
- The company has envelopes that, when closed, can only be opened by the company. The company and the courier go together to a trusted third party — a notary — which makes the company provide documentation to prove its identity. The notary certifies the company’s secure envelopes and the courier takes these back to the client.
- The client gets the envelopes and, if it trusts the notary’s reputation, can be sure that they are actually from the company indicated.
- The client also has secure envelopes that, once sealed, only the client can open. It puts some of these in one of the company’s secure envelopes and sends them back to the company.
- The company gets the sealed secure envelope. It opens the envelope (as only it can). It now has the client’s secure envelopes.
- The company has another kind of envelope that can be opened and sealed only by using a special combination. The company puts this special envelope with the combination lock, together with the combination, into one of the client’s secure envelopes. The company seals the envelope.
- The company has another type of secure envelope that anyone can open, but which only the company can seal. If you open one of these sealed envelopes, you know for sure that it was sent by the company. The company puts the whole package inside this and sends it to the client.
- When the client gets the secure envelope, it opens it and thus knows that it came from the company. It then opens the next secure envelope inside that can only be opened by the client. Inside it gets out the combination-envelope and the combination itself.
- The client the puts his data in the combination envelope, seals it and sends it to the company.
- The company receives it, opens it, and puts the response in the same secure envelope and sends it back.
- The procedure is repeated as often as necessary for required communications.
SSL in Action
So, let’s see how SSL actually works for securing your communications over the Internet. Before the communications occur, the following takes place:
- A company wishes to secure communications to their server company.com.
- They create a public and private key for company.com (this is also known as as “SSL Certificate“).
- They go to a trusted third party company such as Thawte or Verisign: Thawte makes the company prove its identity and right to use the company.com domain. This usually involves a lot of paperwork and paying a hefty fee.
- Once the verification is complete, Thawte gives the company a new public key that has some additional information in it. This information is the certification from Thawte that this public key is for the company and company.com and that this is verified by Thawte. This certification information is encrypted using Thawte’s private key… we will see why below.
Then, when Client wishes to communicate with the company at company.com
- Client makes a connection to company.com with its computer. This connection is made to a special “port” (address) on company.com that is set up for SSL communications only.
- When Client connects to company.com on its SSL-secured port, the company sends back its public key (and some other information, like what Ciphers it supports).
- Client gets the public key and decides if it is OK…
- If the public key has expired, this could be a problem
- If the public key claims to be for some domain that is not company.com that could be a problem.
- Client has the public key for Thawte (and many other third party companies) stored in its computer — because these come with the computer. Thus, client can decrypt the validation information, prove the validation is from Thawte and verify that the public key is certified by Thawte. If Client trusts Thawte, then Client can trust that he/she is really communicating with Company. If Client doesn’t trust Thawte, or whatever Third Party company is actually being used, then the identity of who is running the computers to which Client is connecting is suspect.
- If the client doesn’t trust the server, then the communication is terminated.
- If the client has its own SSL certificate installed, it may send that to the server at this point to see if the server trusts the client. Client-side SSL certificates are not commonly used, but provide a good way for the client to authenticate itself with the server without using a username or password. In the case where this is used, the server would have to know about the client’s certificate and verify it in a similar way to how the client verified the server. If this fails, the connection is terminated. If a client-side certificate is not needed, this step is skipped.
- Once the client is happy with the server (and the server with the client, if needed), then the client choose an SSL Cipher to use from the list of encryption methods provided by the server, and generates a “symmetric key” (password) for use with that Cipher. The client encrypts this password using the server’s public key and sends it back to the server. The server (and only the server) can decrypt this message and get this password, which is now shared by both the client and server.
The client will then start communicating with the company by encrypting all data using this password and the chosen Cipher. Normal “symmetric” (password-based) encryption takes place from this point forward because it is much faster than using the public and private keys for everything. These keys were needed to enable the company (and possibly the client) to prove its identity and right to domain.com and to enable the client and server to generate and securely communicate a common password.
What Services Can be Protected With SSL?
Almost any Internet service can be protected with SSL. Common ones include WebMail and other secure web sites such as banking sites and corporate sites, POP, IMAP, and SMTP. LuxSci provides SSL services to protect your username, password, and communications over all of these and other services.