CHAPTER 34. The Secure Sockets Layer (SSL) Protocol
SOME OF THE MAIN TOPICS IN THIS CHAPTER ARE
Symmetric and Asymmetric Encryption 648
Does SSL Provide Enough Security for Internet Transactions? 652
Sending important information across the Internet, such as your credit-card numbers, can be a problem when using a clear-text method. Using cleartext is just about as bad as giving your credit-card number to a telephone solicitor. If you don’t know who’s on the other side of the transaction, can you be sure that your information will be kept secret?
In the case of Internet transactions, you should first be sure that you are dealing with a reputable vendor that has adopted a good privacy policy—and that the vendor is not a fly-by-night Web site. This may be difficult at times, because there are so many Web sites that will sell you everything you can imagine. As always, if it’s too good to be true, then it probably isn’t. Yet if you are making a purchase from a reliable vendor, you need to further be sure that your credit-card information (as well as other privacy information, such as your name and address) are kept confidential between you and the vendor.
Determining whether a vendor is reliable is beyond the scope of this book. But the subject of this chapter, the Secure Sockets Layer (SSL) protocol, still plays an important role in ensuring secure data transfers across the Internet. SSL provides the means of authentication, proving that the server is who it says it is, and possibly vice versa. To facilitate this authentication, SSL implements a key exchange that is used to encrypt data transfers.
Just as a clear-text transaction is not acceptable on a small network, or a large intranet, the same applies to the Internet. And indeed, with the many millions of Web sites on the Internet, the security problems are exponentially greater than on a company network or small LAN.
The Secure Sockets Layer protocol was developed to address just that kind of situation. Any information you exchange between your computer and a vendor on the Internet can be encrypted and offer you a great deal of security. Note that this does not prevent a hacker from infiltrating a Web site and stealing credit card or other personal information if that information is not encrypted or otherwise securely stored. SSL just protects the transactions that occur between you and the Internet vendor. This is another reason you should choose carefully the dealers you interact with on the Interact.
Note
The Secure Sockets Layer was originally developed by Netscape. It was adopted by both Netscape Navigator and Microsoft’s Internet Explorer, as well as many other browsers. SSL is a common method today for exchanging secure transactions on the Internet. An Internet draft, “The SSL Protocol Version 3.0,” was published in 1996. It is not yet an Internet standard, however.
SSL can be used to authenticate Web servers and clients and to provide a means to encrypt data that flows between them.
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:
- 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.
- The server returns similar information to the client and, if authentication is to be used, the Web server’s digital certificate.
- 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.
- 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.
- 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.
- 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.
Figure 34.1. SSL resides between the Application layer and the Network 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.
Does SSL Provide Enough Security for Internet Transactions?
For the most part, SSL is a very secure mechanism for most data transfers on the Internet. Although SSL is still a proposed standard for the Internet Engineering Task Force (IETF), the IEEE has adopted SSL, and in addition, a successor called Transport Layer Security (TLS), which is also an IETF proposed standard. TLS is built on the SSL protocol, and you can find out more about it by searching at the Web site www.rfc-editor.org.
Before January 2000, the U.S. government prohibited the export of encryption technologies that used keys longer than 40–56 bits. That restriction has been lifted, so applications using 128-bit keys can now be exported, with the exception of countries that the U.S. places trade restrictions on (such as Libya and Cuba). Thus, it is now possible to ensure a great deal of security when transacting with Web sites in various countries. Keep in mind, however, that securing a session is one thing. Trusting the Web site to be a reliable vendor is another.
OpenSource SSL
Major Web servers today (such as Microsoft IIS, Apache, and Netscape) all provide SSL. However, for those that do not, you can find several places on the Internet that you can use to download source code for SSL, including www.openssl.org.