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

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 make an analogy between 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 trying to fool you.

● Eavesdropping? 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 results in two very real security issues for communications over the Internet: 1. knowing for sure that you are connecting to the right computers

(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 the communications. How can s/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 relies on the concept of “public key cryptography” to accomplish these tasks. In normal 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 passwords to

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 user’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 and secure,

and private.

If John 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 John 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:

● 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 a “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.

● 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 client decides to trust the public key, then Client will send to the company the Client’s public key.

● The company will then generate a “password” and encrypt it using both Client’s public key and Company’s private key, in succession, and

send it back to the client.

● Client will decrypt the password. This process proves that the company sent the password and that only Client was able to read it.

● Client will start communicating with the company by encrypting data using this password. 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 to prove its identity and right to domain.com and to give client the password in a safe way.

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. Older “40bit” keys can be broken by trial

and error if one has access to vast computer resources and a good amount of time. These days, keys used in SSL are 128bit or better. There are so

many possible keys with 128bit that it would take significantly longer than the age of the universe to “guess” one.

Trust: While use of SSL ensures that your communications cannot be spied on, it comes down to trust to ensure that you are actually

communicating with your intended company. This is reflected in the validation of company.com and your trust of the third party organization. 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 are almost

free and which spend very little effort in validating the company. In these cases, SSL provides you with 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.

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 “non trusted 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 wary.

Ciphers: SSL uses one of a large variety of possible “ciphers” 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. See: 256-bit AES

Encryption for SSL and TLS: Maximal Security.

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.

256-bit AES Encryption for SSL and TLS: Maximal Security

SSL and TLS are the workhorses that provide the majority of security in the transmission of data over the Internet today. However, most people do

not know that the degree of security and privacy inherent in a "secure" connection of this sort can vary from "almost none" to "really really good …

good enough for US government TOP SECRET data". The piece which varies and thus provides the variable level of security is the "cipher" or

"encryption technique". There are a large number of different ciphers — some are very fast and very insecure. Some are slower and very secure.

Some weak ones (export-grade ciphers) are around from the days when the USA did not permit the export of decent security to other countries.

AES, the Advanced Encryption Standard, is a relatively new encryption technique/cipher that is the successor of DES. AES was standardized in

2001 after a 5 year review, and is currently one of the most popular algorithms used in symmetric key cryptography (which, for example, is used for

the actual data transmission in SSL and TLS). It is also the "gold standard" encryption technique; many security-conscious organizations actually

require that their employees use AES-256 (256-bit AES) for all communications.

This article discusses AES, its role in SSL, which web browsers and email programs support it, how you can make sure that you only use 256-bit

AES encryption of all secure communications, and more.

More about AES

AES has been available in most cryptographic libraries for a long time. It was available in "OpenSSL" starting in 2002 with v0.9.7. OpenSSL is the

foundation of most SSL services in UNIX and Linux environments, such as that used by LuxSci. GPG, the open source implementation of PGP, also

include an AES 256 option.

So, while AES is the new kid on the block, it has been around long enough to permeate most software. However, as we shall see, this does not

mean that is its actually being used on your computer!

How Secure is 256-bit AES?

AES is FIPS (Federal Information Processing Standard) certified and there are currently no known non-brute-force direct attacks against AES

(except some side channel timing attacks on the processing of AES that are not feasible over a network environment and this not applicable to SSL

in general). In fact, AES security is strong enough to be certified for use by the US government for top secret information.

The design and strength of all key lengths of the AES algorithm (i.e., 128, 192 and 256) are sufficient to protect classified information up to

the SECRET level. TOP SECRET information will require use of either the 192 or 256 key lengths. The implementation of AES in products

intended to protect national security systems and/or information must be reviewed and certified by NSA prior to their acquisition and

use." (Lynn Hathaway, June 2003 - reference.)

If you have the choice of encryption methods, 256-bit AES is the method to choose. Also good are 128-bit and 192-bit versions of AES.

And there alternatives to AES?

There are many alternative ciphers that can be used in SSL and TLS. The "next most secure" cipher that is commonly used is "128-bit RC4". This is

a very fast cipher, but is subject to many different types of attacks. For example, on reason WEP wireless encryption is so poor is the way that it

uses RC4 encryption. Even WPA wireless security which uses RC4 is showing signs of stress.

RC4 encryption is felt very weak by most security researchers and is not recommended for use. However, it is still "second best" to AES in the list of

commonly used ciphers and widely used.

How is the cipher chosen in an SSL or TLS session?

In general, when an SSL client, such as an email program or web browser, connects to a server and wishes to use SSL or TLS, the client sends the

server a list of encryption ciphers that it supports. The server then goes through the list, in order, and chooses the first match that it also supports.

Usually, the client orders the list with the most secure methods first, so that the most secure method supported by both the client and server is

selected. Sometimes, the client orders the list based on other criteria to make a compromise between security and speed; this can result in a sub-

optimal cipher being chosen.

Most modern web and email servers that support SSL encryption, like LuxSci.com’s servers, support many different strong encryption techniques all

the way up to 128-bit RC4 and 256-bit AES. They provide a variety, instead of just a single really good method, so that users who have old or
broken software can still take advantage of encryption, even if it is weaker than it should be. Additionally, most companies that provide security

services do not permit use of techniques that deemed are "too weak" and which can be broken very easily (like the old "export grade ciphers" that

used to be in prevalent use). So, if you are connecting to a reputable service provided over SSL or TLS, the type of encryption that will be used is

almost certainly determined by your client program (i.e. email program or web browser).

What encryption techniques are supported by modern web browsers?

For any given web browser, it is easy to see what the best encryption technique it supports by browsing to the web site: https://www.fortify.net/cgi/

ssl_2.pl

Checking out some of the current browsers available, we see:

Web Browser Operating System Best Cipher Verdict?

FireFox v3.0.5 Windows XP & Vista AES 256-bit Good!

FireFox v3.01 Mac OSX 10.5.5 AES 256-bit Good!

Safari v3.2.1 Windows XP RC4 128-bit Fair

Safari v3.2.1 Windows Vista AES 128-bit Good

Safari v3.2.1 Mac OSX 10.5.5 AES 128-bit Good

Safari iPhone v2.2 AES 128-bit Good

Chrome v1.0.154.43 Windows XP RC4 128-bit Fair

Chrome v1.0.154.43 Windows Vista AES 128-bit Good

Internet Explorer v7 Windows Vista AES 128-bit Good

Internet Explorer v8 beta Windows XP RC4 128-bit Fair

Internet Explorer v7 Windows XP RC4 128-bit Fair

Internet Explorer v6 Windows XP RC4 128-bit Fair

Opera v9.62 Windows XP & Vista AES 256-bit Good!

So, by default, only some browsers will take advantage of AES encryption, when available. We also see that any program that uses the windows

default SSL libraries, will use RC4 in Windows XP and 128-bit AES in Windows Vista. So, anyone using Windows XP (or 2000) should really use a

program that includes its own SSL cipher management (i.e. FireFox, Opera).

What encryption techniques are supported by modern email programs?

Asking this question about web browsers begs the question as to what is supported by the various email programs out there. Clearly, if you are

using a WebMail interface to your email, then the answer depends on what web browser you are using.

We tested several popular email programs to see what encryption cipher they end up using when connected to a server like LuxSci’s that supports a

variety of strong ciphers.1 Here are the results:

Email Program Operating System Verdict? Results

Mozilla Thunderbird v2.0.0.19 Windows XP & Vista Good! 256-bit AES

Thunderbird v2.0.0.19 Mac OSX v10.4.11 Good! 256-bit AES

Fair
Outlook 2007 Windows XP 128-bit RC4 is the best supported

128-bit AES chosen (though 256-bit is there, it is not listed 1st in the program and
Outlook 2007 Windows Vista Good
thus not used)

Outlook 2003 Windows XP Fair 128-bit RC4 is the best supported

 128-bit AES chosen (though 256-bit is there, it is not listed 1st in the program and
Mail.app Mac OSX v10.5.5 Good
thus not used)

128-bit AES chosen (though 256-bit is there, it is not listed 1st in the program and
Mail.app Mac OSX v10.4.11 Good
thus not used)

128-bit AES chosen (though 256-bit is there, it is not listed 1st in the program and
Mail.app iPhone v2.2 Good
thus not used)

Eudora v7.1.0.9 Windows XP Good 256-bit AES

Eudora v8.0.0b4 Mac OSX v10.4.11 Good 256-bit AES

Entourage v12.1.5 Mac OSX v10.4.11 Fair DES

We see a similar pattern here. Some clients roll their own SSL (i.e. Thunderbird) and some use Windows’ built-in libraries.

How to force use of 256-bit AES for secure web and secure email

As discussed above, the choice of email client is the prime determination of what encryption cipher will be used. So, for example, if you use Mozilla

Firefox or Opera for web browsing and Mozilla Thunderbird for email, you will be using 256-bit AES encryption, as long as it is supported by the

server.

However, if you would like to go a step further and be sure that you do not make any secure connection at unless 256-bit AES encryption is used,

that is also possible. This level of security is needed if your organization mandates that secure connections use 256-bit AES, or if you do not trust

that all of the servers which you connect to will have good security ciphers in place. Following the instructions below for FireFox and Thunderbird,

you can be sure that 256-bit AES will be used for all secure connections; the connections will flat out fail if the server doesn’t support this encryption

technique.

Mozilla Firefox (v3):

1. Type "about:config" in the address bar to open up the detailed list of configuration parameters.

2. Make sure that "secuity.enable_ssl2" is "false" and "security.enable_ssl3" and security.enable_tls" are "true".

3. Search for "security.ssl3"

4. Change to "false" the value for all ciphers that do not include "aes_256" in the name. This will make them no longer available for use.

5. You will be left with various versions of AES 256 in SSL v3 or TLS.

6. You don’t even have to restart Firefox for this to take effect!

Mozilla Thunderbird (v2): (see also optimization tips for Thunderbird)

1. Select "Options" from the "Tools" menu

2. Under the "General" section of the "Advanced" tab of the resulting "Options" dialog box, click on the "Config Editor…" button.

3. Follow the same instructions as for Firefox in terms of disabling SSL2, enabling SSL3 and TLS, and turning off all ciphers that do not include

"aes_256" in the name.

4. Restart Thunderbird so that any persistent connections are broken and re-opened.

5. Make sure that your email accounts are all configured to use SSL or TLS (not "if available", but "always").

6. If possible at your email provider, disallow insecure connections to your account altogether. This will make the connection fail even if the

email program is accidently configured to make a secure connection. (LuxSci allows this to be set on the user-level or to be enforced by

policy account-wide).

Skype:

● Off topic, but Skype uses 256-bit AES encryption, so if you use it for chat or voice calls, your data is also being encrypted in this fashion.

Windows Vista

Windows Vista, we have seen, does support 256-bit AES, but it publishes 128-bit first in the list and thus this is what is used by most applications in
a Vista environment that rely on Vista’s built-in SSL libraries (i.e. Internet Explorer, Outlook, etc.).

If you have Vista "Small Business Edition" or better, you can remove ciphers that you do not want and change the order of their presentation by

using the "group policy editor". For example, to make 256-bit AES the default choice, rather than 128-bit AES, follow these instructions:

1. Open your group policy editor by entering gpedit.msc at a command prompt.

2. Choose Computer Configuration | Administrative Templates | Network | SSL Configuration Settings.

3. There’s only one item here: SSL Cipher Suite Order. Open it.

4. Select Enabled.

5. Now here’s where you need to tread carefully. You’ll see that the list is the same as above, but rather than formatted nicely with

carriage returns, they’re simply separated with commas. The first item in the list is:

TLS_RSA_WITH_AES_128_CBC_SHA

And the second item is:

TLS_RSA_WITH_AES_256_CBC_SHA

Cursor your way through the list. Change that first 128 to 256. Then cursor forward a bit more and change the 256 to 128.

6. Feel free to change other orders, too, but keep your changes within algorithm types.

7. OK your way out, close the group policy editor, and reboot.

Similarly, you can use the same procedure to remove all ciphers that are not wanted and thus lock down your Vista to AES-only encryption or 256-bit

AES only encryption.

However, for those of us who have Vista Home Basic or Premium Edition, there is no "group policy editor" (and if you copy it from another Vista, it

won’t run) and it is thus much harder to make this change. All of the settings that you would be changing above are found in the Windows Registry

and can be changed directly therein. We are not going to go into how to do this here, as it is not for the faint of heart.

Locking down your web site (in Apache)

If you are the owner of a web site and have SSL security on it, you can "lock it down" so that the only cipher that your web site supports is "256-bit

AES". This takes the choice out of the end user’s hands — either they use AES or they don’t connect securely. This is a good thing to do for very

sensitive sites. However, the "danger" is that some of your users may be using web browsers that do not support AES (like Internet Explorer), and

thus will not have any access to your site unless they change browsers.

To lock your site down to support 128-bit and 256-bit AES only (to get AES but not require 256-bit, so that some browsers like iPhone and such will

work), you would add to your Apache httpd.conf file:

SSLCipherSuite AES256-SHA:AES128-SHA

This can be added globally, in a virtual host, or even in your .htaccess file. It will ensure that any successful connection to your site will use one of

these ciphers. Just be sure to add it to the secure settings for your site and not just the insecure site area! See more information here.

Conclusion

AES encryption is the way to go when using SSL, if you have any choice about it. It won’t really affect speed or performance as long as your

computer is not ancient. If you have qualms about security, we highly recommend using a web browser and/or email client that will enable use of

AES.

Note that SSL and TLS protect only the data sent between you and the server. When you send and receive email, the message data travels over

the Internet between the sender and recipient and will be unprotected, no matter how good your SSL is. For details on this, read The Case for Email

Security. The solution in this situation, is to use an end-to-end email encryption solution, like LuxSci’s SecureLine, in addition to SSL (SecureLine

protects the message content, SSL protects your username and password).