Symmetric and Asymmetric Encryption

SSL is based on encrypting data between your browser and a Web server. There are other uses for SSL, but this is perhaps the most widespread use. There are two basic methods for encrypting data transactions on a network:

• Symmetric A single key known by both sides of the communication is used to encrypt the data.

• Asymmetric Two keys, called the public key and private key, are used to establish an encrypted data transfer.

When you're using symmetric encryption, there is the problem of exchanging the single key so that both sides can use it to encrypt and decrypt the data. How do you send a secret key to the other party to a transaction? Use snail mail, place a telephone call, or send it as plain-text across the Internet? Obviously, none of these methods is truly secure. Sending the key via the postal service can take a few days or more, and using a telephone conversation for each Web server you want to contact can take more time than it would be worth. And, a plain-text transfer, like the previous two methods, is open to interception by a third party. Letters can be opened and resealed. Telephone conversations can be tapped. Plain-text is easily intercepted on the Internet.

Although this may sound paranoid for a casual user, a large business might think otherwise. It is not uncommon for corporate spies to go through the trash of a company looking for important data. Certain newspapers usually found at the grocery store check-out lane often use this method to get information about public figures, such as movie stars! You can protect sensitive data stored on paper by simply shredding (or burning) it. Protecting data transferred on the Internet is another thing altogether.

Chapter 47, "Encryption Technology," gives a broad overview of technologies used to protect information using encryption techniques, including symmetric and asymmetric encryption, as well as digital certificates discussed in this chapter.

A better method for exchanging the symmetric key is to use public/private (asymmetric) key encryption. This type of exchange can set up an encrypted data path that can then be used to exchange the symmetric key for the remainder of the session.

Asymmetric encryption uses both private and public keys, and enables your browser and the Internet server to exchange data without having to first exchange a single encryption key.

Digital Certificates

SSL depends on a private and public key pair for the initial exchange of the symmetric key, as well as for authentication using digital certificates. Public keys are readily available on the Internet from companies that provide digital certificate services. There are several major providers of these sorts of keys, such as VeriSign (www.verisign.com) and Entrust (www.entrust.com), among many others. Digital certificates are used so that your browser can ensure that the Web server being contacted is indeed who it says it is.

The SSL Handshake Procedure

The SSL handshake procedure uses public/private keys to accomplish the following:

• Determination of the SSL version to be used

• Deciding what type of symmetric encryption will be used

• Server authentication

• Client authentication (optional)

• Exchange of a symmetric key

The exact details of the messages exchanged and the syntax used are a little complicated, but the basic method is as follows:

1. The client sends a request to a server that supports SSL. This message contains such things as encryption techniques and the version of SSL supported by the client, as well as some randomly generated data.

2. The server returns similar information to the client and, if authentication is to be used, the Web server's digital certificate.

3. The client uses the public key obtained from the Web server to encrypt some data and sends this encrypted data to the Web server. If the client wants to authenticate the Web server (to determine that the digital certificate is valid), it can contact the issuer of the certificate (certificate authority, or CA) and compare the data for the copy of the server's certificate. The client uses the public key of the CA to determine whether the CA's copy of the Web server's certificate is valid. If any data does not match the certificate sent to the client by the Web server, the server is not authenticated and the client ends the exchange between it and the Web server.

4. Assuming that the Web server has been authenticated, the client proceeds to encrypt (using the public key found on the Web server's digital certificate) some secret data and sends the message to the Web server. The Web server uses its own secret key to decrypt the secret data sent by the client.

5. Both the client and the Web server then go through several steps, depending on the method chosen for symmetric encryption, to come up with a symmetric session key.

6. The client sends a message (encrypted using the newly created symmetric key) to the Web server. From then on, messages between the client and the Web server will use this key. The server replies using the same method, and both sides of the connection send messages indicating that the handshake process is finished.

The preceding steps describe the basic method used to set up an SSL session. Other steps can also be involved. For example, in these steps the client first authenticated the Web server's certificate by contacting the CA to check the validity of the certificate the client received from the server. The opposite can also be performed: The Web server may need to authenticate the client. This will depend on which way sensitive data is being exchanged. If you are placing an order on a Web site and need to send credit-card information, your browser will definitely want to authenticate the Web server. If the Web server is sending sensitive data to the client (such as when you send confidential data to a customer), the Web server should also authenticate the client so that the server knows that the client is who it appears to be.

Using Information in the Digital Certificate to Prevent Interception Attacks

The preceding section described the basics of SSL. Although the techniques used may appear to be all that is necessary to ensure secure communications, because both sides of the session can authenticate with each other, that is not always the case. In Chapter 47 you will learn about a "man in the middle" attack that is used by hackers for many different protocols. The concept is to place an application between both of the parties to the secure session during the setup phase, and impersonate the server to the client, and the client to the server.

Some of the typical information that is found on a digital certificate includes the following:

• The public key of the CA used by the Web server. This is used to ensure that the certificate issued to the Web server is a valid one, and that the information has not been altered.

• A serial number that uniquely identifies the certificate.

• The time period during which the certificate is valid.

• The server's domain name.

The last item, the server's domain name, is not actually part of the SSL protocol. However, it is used by many browsers. The first three items must match those of the certificate presented by the Web server (or the client in the case of client authentication). The server's domain name, however, is very important.

For example, if the first three items listed are correct (the certificates have not been altered, and the certificate has not yet expired), does that guarantee that the Web server's certificate has not been stolen and is being used by another Web server to impersonate the server that was originally issued the certificate?

The application used to intercept communications between the Web server and the client performs two functions to satisfy both sides of the data exchange, and gain access to the encrypted data that will be sent using SSL:

• It uses its own public or private key to perform the handshake between the Web server and the client so that each side thinks it is talking to the other side of the communication.

• It establishes one symmetric key for communicating with the Web server, and another for communicating with the client.

Using this method is not an easy task. It usually is done by an insider of an organization because intercepting and impersonating clients and the Web sites with which they will establish important sessions is not very profitable, considering the huge amount of traffic on the Internet.

Worse yet is the fact that such a compromise in security can produce bad publicity for your company. Would you want to trust an Internet site with your credit-card number if that site had been hacked recently?

Yet, when this type of attack succeeds, the application that stands between the client and the server can intercept all data from either side. Worse yet, it can modify the data to serve some other purpose. No matter what the reasoning for using this type of attack, and the fact that it is difficult to implement, this threat can be practically eliminated by using the domain name of the client or Web server's digital certificate.

The domain name can be resolved to an IP address. The application that stands between the client and the Web server will have to use a different IP address. Looking up the domain name and checking to see whether the IP address that each side is talking to is accurate usually prevents this kind of attack from occurring.

http:// and https://

When you are using a browser to access a typical Web page, the address field usually begins with http://, followed by the Web site. When using SSL, you'll notice that this text has an extra character added to it: https://. The "s" that is attached to the URL lets you know that SSL is being used. Watch that field. You might start out on a Web page that uses http://. Then when you decide to make a purchase, or conduct some other transaction involving sensitive information, you will usually have to click on a button. The next page that appears should have https:// in the address field. If it doesn't, don't trust that page. Many browsers will also display a padlock icon on the status bar to indicate that you are connected to a secure site.

Adding Another Layer to the Network Protocol Stack

Now that you have a good understanding of how SSL works, you'll want to know where it fits into the protocol stack on your computer. SSL can work with many protocols other than just HTTP. So it needs to be below the Application layer. Yet, because TCP/IP (at the Network layer) is used to ensure reliable communication sessions, SSL needs to be above TCP/IP in the protocol stack. As you can see in Figure 34.1, that is exactly the case. SSL is stuck neatly between these two layers.

HTTP or other protocol

Secure Sockets Layer (SSL)

TCP/IP layer

Another important distinction is that the typical port used for HTTP communications is port 80. For SSL that port is usually 443. Both of these settings can be changed by altering the syntax of the URL in the address fields, but it's best to just use the defaults to ensure compatibility with some Web servers that don't let you use another port.