« blog index

How Does Secure Socket Layer (SSL or TLS) Work?

July 22nd, 2013

The Secure Socket Layer, SSL for short, is a protocol by which enables services that communicate over the Internet to do so securely.

SSL has recently been replaced by TLS (Transport Layer Security).  TLS is newer and more secure than SSL (See TLS vs SSL: What is the difference?); however, from a lay-person’s perspective of “how does it work,” they are functionally the same.  We use the term “SSL” to refer to both TLS and SSL in this article for simplicity.

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

This is, for example, what happens when you go to any web page whose address begins with “http://” (and not “https://”).

Let us compare communications 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 is 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.
  • Eavesdropping? As you are aware of from watching TV or reading, it is very easy to “tap” phone lines: the government and spies do this all the time to covertly gather information (e.g. the NSA PRISM and other surveillance programs). It is not easy to impossible to detect if your lines are tapped. The same applies to 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 or when communicating through large public ISPs like Comcast or Verizon.

This results in two very real security issues for communications over the Internet: 1. knowing for sure that you are connecting to the intended 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 servers: trust and encryption. 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.

Jason wants to communicate using “snail mail” with a company to send important information back and forth (e.g. a bank). Jason wants to be 100% sure that he is communicating with this particular company and that no one can eavesdrop on or intercept the communications.

How can he do this?

  1. Jason sends a courier to the company’s address.
  2. 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 identity and its secure envelopes and the courier takes these envelops back to Jason.
  3. Jason gets the envelopes and, if he trusts the notary’s reputation, he can be sure that they are actually from the company indicated (trust is established).
  4. Jason also has secure envelopes that, once sealed, only Jason can open. He puts some of these in one of the company’s secure envelopes and sends them back to the company.
  5. The company gets the sealed secure envelope. It opens the envelope (as only it can). It now has Jason’s secure envelopes.
  6. The company has another kind of envelope that can be opened and sealed only by using a special combination (e.g. a security code). The company puts this special combination-envelope, together with the appropriate combination, into one of Jason’s secure envelopes. The company seals the envelope.
  7. 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 Jason.
  8. When Jason gets the secure envelope, he opens it and thus knows that it came from the company. He then opens the next secure envelope inside that can only be opened by Jason. Inside, Jason finds the combination-envelope and the combination itself.
  9. Jason puts his data in the combination envelope, seals it with the combination, and sends it to the company.
  10. The company receives it, opens it, and puts the response in the same secure envelope and sends it back.
  11. The procedure is repeated as often as necessary for required communications.

Jason has been able to trust that he is talking to this bank and he has also established secure communications with the bank.

How does this apply to SSL?

SSL relies on the concept of “public key cryptography” to accomplish these same tasks. In normal “symmetric” encryption, the two parties communicating share a “password” and that password is used to both encrypt and decrypt messages. While this is fast and efficient, how do you communicate the shared passwords with people you have not yet met in a way that is itself secure?

In “public key cryptography”, each person has two keys — a “public” key and a “private” key. Anything encrypted with the person’s public key can only be decrypted with the private key and vice versa. Each person then tells the world what his public key is and keeps his private key safe, secure, and, well, private.

If Jason sends Mary a message encrypted with Mary’s public key, then only Mary can open it, as only she has her private key. This is like an envelope that anyone can seal but which only Mary can open.

If Jason sends Mary a message encrypted with John’s private key, then anyone can open it, as everyone has access to John’s public key.  However, successfully opening the message proves that it was sent by John and no one else, as only John has access to his private key. This is like an envelope that only John can seal, but which anyone can open and thus prove that John sealed it.

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:

  1. A company wishes to secure communications to their web server company.com.
  2. They create a public and private key for company.com (this is also known as an “SSL Certificate“).
  3. 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 some paperwork and a fee.
  4. 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, that this has been verified by Thawte, and that this is valid for a certain period of time. This certification information is encrypted using Thawte’s own private key… we will see why below.

Then, when Jason wishes to communicate with the company at company.com,

  1. Jason makes a connection to company.com from his computer (e.g. from his web browser if this is a web site). This connection is made to a special “port” (address) on company.com that is set up for SSL communications only (alternately, Jason could connect to a non-secure port and the initiate a secure connection after the fact … see SSL vs TLS – what’s the difference).
  2. Jason connects to company.com on its SSL-secured port, indicating that he wants a secure connection and specifying what level of SSL security he knows how to use (e.g. what versions and Ciphers his programs can use), the company sends back its public key (and some other information, like what Ciphers will actually be used).
  3. Jason gets the public key and decides if it is “OK”…
    1. If the public key has expired, this could be a problem (these are only valid for a certain number of years before they have to be re-verified)
    2. If the public key claims to be for some domain that is not company.com that could be a significant problem.
    3. Jason has the public key for Thawte (and many other third party companies) stored in its computer — because these come with the computer. Thus, Jason can decrypt the validation information, prove the validation is actually from Thawte, and verify that the public key is certified by Thawte. If Jason trusts Thawte, then he can trust that he is really communicating with Company. If Jason doesn’t trust Thawte, or whatever Third Party verification company is actually being used, then the identity of who is running the servers to which Jason is connecting is suspect.
  4. If Jason doesn’t trust the server, then the communication is terminated before anything sensitive is communicated.
    1. Note: If Jason has his own SSL certificate, he may send that to the server at this point to see if the server trusts Jason.  These “Client-side SSL certificates” are not commonly used, but provide a good way for users like Jason to authenticate themselves with a server without using a username or password (or in addition to doing so, as a second factor).  In cases where this is used, the server would have to already know about the Jason’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.
  5. Once Jason is happy with the server (and the server with Jason, if needed), then he can generate a “symmetric key” (a password) for use with the Cipher chosen by the server.  Jason encrypts this key 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 key, which is now shared by both Jason and server.
  6. Jason will then start communicating with the company by encrypting all data using this key 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. The public and private keys were needed to enable the company (and possibly Jason) to prove its identity and right to domain.com and to enable Jason and server to generate and securely communicate the unique, shared password for the rest of the dialog.

So, Are there Limitations to This Process?

This all sounds great — what are the down sides? There are a few.

Key Length:

The statement that “only someone with the private key can decrypt something encrypted with the public key” is true so long as the private key cannot be “guessed.” Hackers may try to do this by trying all possible private key combinations, or by using tricks which involve knowing something about the communications (e.g. some of the plain text, or many different encryptions of the same unknown plain text, etc.), or by using flaws in the encryption algorithms.

Older short keys can be broken by trial and error if one has access to significant computer resources and a good amount of time. These days, keys used for SSL certificates are generally “2048 bit” or greater to make them safe from such attacks (for a good while still).  Similarly, ciphers used for symmetric encryption used in SSL are “128 bit” or better. There are so many possible passwords with 128 bit that it would take significantly longer than the age of the universe to “guess” one.  The real danger is the cipher algorithm, more than the key length.

Trust:

While use of SSL ensures that your communications cannot be spied on, it comes down to trust to ensure that you are truely communicating with your intended company. This is reflected in the validation of company.com and your trust of the third party organization doing that. Some “secure sites” do not bother to get a third party’s approval and have their keys approved by “themselves.”  Others use third parties that free or are almost free and which spend very little effort in validating the company. In these cases, SSL provides you with little or no real assurance that you are really talking to your intended company and not some hacker trying to forge their identity to communicate with you in a manner in which you think you are safe. (e.g. see how Gogo Inflight Internet used faked and untrusted SSL certificates to  interfere with secure communications).

For defensive use of the web, you should pay attention to warnings generated by SSL when you connect to secure sites. Such warnings include “expired certificates,” “domain name mismatches” — where the domain name presented by the company is different than the one to which you are connecting, and “untrusted certificates” — where the public key (certificate) presented by the company was not validated by a third party that your computer trusts. In all of these cases, you should be very wary.

You should also look for a “Green Address Bar” in your browser window as this indicates that the site uses an “Extended Validation SSL Certificate” which costs a lot more for a lot more vetting of the company’s identity.  Organizations that are security conscious use these to enable end users to easily visually see that their sites are trusted.

Ciphers:

SSL uses one of a large variety of possible “ciphers” (encryption algorithms) to perform the symmetric encryption.

Use of a poor/weak cipher can result in fast SSL that is easily compromised.  Currently, it is recommended that one use 128-bit or stronger AES encryption as your cipher for SSL in general.  See: 256-bit AES Encryption for SSL and TLS: Maximal Security.  For HIPAA-compliant web sites and sites requiring a strong level of encryption, there are well documented lists of ciphers that should be used, as others may be considered insecure.

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, MySQL, ActiveSync, POP, IMAP, and SMTP. LuxSci provides SSL services to protect your username, password, and all communications over all of these and other services.

References

This entry was posted on Monday, July 22nd, 2013 at 7:01 am and is filed under AAA Featured Articles, LuxSci Library: Security and Privacy, LuxSci Library: The Technical Side of Email, Popular Posts.