If you have a secure server, you can use the security built into it to provide a secure environment for you and your users to conduct business transactions.
This chapter provides an overview of security and explains the different security protocols.
The Internet was not originally designed to protect sensitive or confidential data. However, with the advent of electronic commerce, such as online shopping and online bill paying, information privacy becomes necessary. In addition, intra-company communications over the Internet often contain confidential product information that needs to be protected from general access. Routing computers can listen to and record any communications that pass through.
Think of the Internet as a new postal service. This new service operates at blinding speed, sorting and routing messages through various post offices in seconds.
Unfortunately, this new postal service has an awkward twist to it. Anyone and everyone can be a postmaster, and there is nothing to prevent a postmaster from reading, copying, and even altering the mail as it passes through the post office. Another drawback is the lack of receiver accountability, for items such as registered letters that require signatures or return receipts. As a result, you cannot be sure that the intended recipient received the mail you sent.
Because the Internet was designed to be an open system, it allows any computer on the network to see the messages passing through. You can safely estimate that 20% of the messages you send on the Internet will be copied and stored somewhere by someone else for future reference. Because most messages are sent as plain block text, there is no limit to the different software platforms that can read, copy, and possibly alter the messages you send.
You would never think of sending your medical records or paying your bills by postcard. By the same token, few people want to use the Internet, in its present form, for commercial exchanges without additional security.
You can consider an information transaction to be secure if it has these characteristics:
Confidentiality means that the contents of the messages remain private as they pass through the Internet. Without confidentiality, your computer broadcasts the message to the network, similar to shouting the information across a crowded room. Encryption ensures confidentiality.
Integrity means that messages are not altered while being transmitted. Any router along the way can insert or delete text or garble the message as it passes by. Without integrity, you have no guarantee that the message you sent matches the message received. Encryption and digital signature ensure integrity.
Accountability means that both the sender and the receiver agree that the exchange took place. Without accountability, the addressee can easily say the message never arrived. Digital signature also ensures accountability.
Authenticity means that you know who you are talking to and that you can trust that person. Without authenticity, you have no way to be sure that anyone is who they say they are. Authentication ensures authenticity.
Encryption in its simplest form is scrambling a message so that it cannot be read until it is unscrambled later by the receiver. The sender uses an algorithmic pattern, or key, to scramble, or encrypt, the message. The receiver has the decryption key. Encryption ensures confidentiality in transmissions sent over the Internet.
There are two kinds of keys that can be used for encryption (as well as for digital signature and authentication):
The risk involved with symmetric keys is that you have to find a safe transportation method to use when sharing your secret key with the people with which you want to communicate.
With asymmetric keys, you create a key pair.
The key pair is made up of a public key and a private key, which are different from each other. The private key holds more of the secret encryption pattern than the public key.
As a sender, you can then broadcast your public key to whomever you want to communicate securely. You hold on to the private key and protect it with a password.
Unlike symmetric keys, the private key and the public key are not the same. As a result, only you can decrypt a message that has been encrypted with your public key, because only you have the private key.
A protocol like Secure Sockets Layer (SSL) uses both public key cryptography and symmetric key cryptography. Public key cryptography is used for the TCP/IP handshake. During the handshake the master key is passed from the client to the server. The client and server make their own session keys using the master key. The session keys are used to encrypt and decrypt data for the remainder of the session.
Authentication is the process used to verify identity, so that you can make sure that others are who they say they are. There are two ways in which the server uses authentication:
A digital signature is a unique mathematically computed signature that ensures accountability. You can think of a digital signature as being like a credit card with your picture on it. But how do you know if the person sending you a message is who he says he is?
You look at the sender's digital certificate. A digital certificate is like a credit card with a picture of the bank president with his arm around you. A merchant will trust you more because not only do you look like the picture on the credit card, the bank president trusts you, too.
You base your trust for the authenticity of the sender on whether you trust the third party (a person or agency) that certified the sender. The third party or certification authority (CA) issues digital certificates.
A certificate is made up of:
The Distinguished Name is the name and address of a person or organization. At a minimum, it is someone's name. You enter your Distinguished Name as part of requesting a certificate. The digitally-signed certificate includes not only your own Distinguished Name, but the Distinguished Name of the CA.
CAs broadcast their public key and Distinguished Name bundled together so that people will add them as a trusted root key to their Web servers and browsers. When you designate the public key and certificate from a certification authority to be a trusted root key means that your server will trust anyone who has a certificate from that certification authority. You may have many trusted roots as part of your server. In fact, the server includes several default trusted root keys, and you can add others as needed.
In order to communicate securely, the receiver in a transmission must trust the CA that issued the certificate that the sender is using. This is true whether the receiver is a Web server or browser. As a result, any time a sender signs a message, the receiver must have the corresponding CA certificate and public key designated as a trusted root key.
SSL is a security protocol that was developed by Netscape Communications Corporation, along with RSA** Data Security, Inc. This protocol ensures that data transferred between a client and a server remains private. It allows the client to authenticate the identity of the server. In addition, SSL V3 allows the server to authenticate a client. If SSL client authentication is set up, the server requests the client's certificate for any https request. The server establishes a secure session whether or not the client has a valid certificate. SSl client authentication parameters can be specified in protection setups, ACL files, or both as described in Chapter 7. "Protecting your server". If you specify SSL client authentication parameters, the server validates the DN information in the parameters with the DN information in the client's certificate before serving the document.
Once your server has a digital certificate, SSL-enabled browsers like the IBM Secure WebExplorer and Netscape** Navigator can communicate securely with your server using SSL. With SSL, you can easily establish a security-enabled Web site on the Internet or on your corporate TCP/IP network.
SSL uses a security handshake to initiate the TCP/IP connection between the client and the server. During the handshake, the client and server agree on the security keys that they will use for the session and the algorythms they will use for encryption and to compute message digests or hashes. The client authenticates the server. In addition, if the client requests a document protected by SSL client authentication, the server requests the client's certificate. After the handshakes, SSL is used to encrypt and decrypt all of the information in both the https request and the server response, including:
For more information on how to use SSL, see Chapter 10. "Using Secure Sockets Layer (SSL)".
The server uses the public key cryptography from RSA Data Security, Inc., for encryption, message digest, and authentication. RSA public key cryptography is commonly used in the computer industry.
We provide forms that you can use to manage your keys, key ring file passwords, certificates, and trusted roots. A key ring file is a file where you keep public keys, private keys, certificates, and trusted root keys.
As discussed earlier in this chapter, public key cryptography uses a pair of asymmetric keys for encryption and decryption.
When you create a key pair, you are asked to provide the name of the key ring where you want to keep the key pair and a password for the key ring. Then, whenever you want to use a Key Management form, such as Designate Trusted Root Keys, you'll be asked for the key ring password.
The default trusted root keys that are part of the server will automatically be added any time you create a key ring.
The server also provides you with the ability to:
You can access these key management functions from the Key Management form. To access this form:
The key management forms require that you enter the key ring password before you can use them. If you have multiple key rings, always make sure that you are making changes to the correct key ring by checking the key file name and path displayed on the form. When you complete your key management tasks, always make sure that the key ring that contains the server's keys you want to use for secure communications is the current key ring. You can use the Security Configuration form to designate a key ring as the current key ring.
When you apply the changes you've made to a security form, you will receive a confirmation message that the changes have been successfully completed. You can make changes to other Configuration and Administration forms. However, when you are ready for the changes you've made to any security forms to take effect, you must stop the server and then start it again. The server will not pick up your changes if you only restart it.
Use the Change Password form to change the password for the current key ring file.
The current key ring file name is displayed. To change your password:
Enter the current password used to protect the key ring file.
Use this part of the form to specify the new password to protect your key ring. The password must be from the U.S. English character set.
The password is important because it protects a private key. The server uses its private key to decrypt messages from clients and to sign messages to clients. The CA private key is used to sign the client and server certificates processed by the certutil command.
The security of a private key depends upon this password. Here are some commonly accepted rules for specifying passwords:
Type the password twice to ensure that you have typed it correctly.
If you must record the password, make sure it is stored in a well-secured place.
The key ring password must be specified when the server is started. Check Automatic login if you want the server to stash the password and specify it for you whenever the server is started. To stash the password, the server encrypts the key ring password and puts it in a file that has the same name as the key ring file, except the extension is .sth.
Stashing the server's key ring password is less secure so it's generally a good practice not to stash it. However, there may be cases where you need to stash the password; for example, if you have a remote server and you want it to automatically restart after a power failure.
Note: If you installed your server as an NT service, you must stash the password. If the password is not stashed, the server will start but you won't have any security.
If you are changing the CA key ring password, do not stash it.
Select whether you want the password to never expire or the length of time you want the password to be active. If you do select an expiration date, a message is written to the error log when the password expires.
Use the Manage Keys form to set a private key as the default key. The default key should be the private key the server uses for its secure communications.
The current key ring file name and default key are displayed. To set a key as the default:
Select the key you want to set as default, as long as it is not a trusted root key. You cannot set a trusted root key as a default because trusted root keys cannot send and receive messages. The trusted roots are marked with an asterisk (*).
Select this radio button to set the key as the default.
Use the Manage Keys form to delete a key from the current key ring file.
The current key ring file name and default key are displayed. To delete a key:
Select the key you want to delete. The default trusted roots are marked with an asterisk (*).
Select this radio button to delete the key.
If you need to transfer a key pair or certificate to another computer, you can export it to a file. On the other computer, you can import it into a key ring.
Use the Export Keys form to export a key pair or certificate to a file.
To export:
Select the key pair or certificate that you want to export. Trusted root keys are designated with an "*". You may need to transfer a key pair for your own use; however, keep in mind that a key pair contains the private key, which should never be transmitted to others. The private key is what the server uses to sign messages and also to decrypt messages that clients have encrypted with the server's public key. If you are acting as your own CA for a private Web network, the CA private key is used to sign the certificates you process as CA. If the CA private key is compromised, then all the certificates issued by you as a CA are also compromised.
Enter the name of the file to which you want to export the key pair or certificate.
Enter the password you want use to protect the export file. Then enter it again for verification. The export file will be encrypted using this password.
Use the Import Keys form to import a key pair or certificate from a file and add it to a key ring file.
To import a key pair or certificate:
Enter the name of the file from which you want to import the key pair or certificate.
Enter the password that was used to protect the export file.
Your public key must be tied to a digitally signed certificate from a (CA). There are two different ways that you can obtain a certificate:
It's not a good practice to share certificates among servers. As you'll see later, the server's keys are kept on a key ring with the server's certificate. You do not want servers to share a private key, particularly if they are running on different machines. A private key should never be communicated to others.
VeriSign** certificates can't be shared among servers on different machines.
You can buy a signed certificate by submitting a certificate request to a CA. VeriSign, Inc. will issue certificates to Internet Connection Secure Server customers. We expect that there may be other certification authorities over time.
VeriSign will expect you to prove who you are before they will issue you a certificate. Although the approval process is necessary to protect you, your organization, and VeriSign, it may take longer than you would like. VeriSign will digitally sign your certificate request and return the unique certificate to you through e-mail. After you have received the certificate into the file system, you can use the Configuration and Administration forms to receive the certificate into a key ring.
For more detailed step-by-step information on how to request a certificate, see Chapter 10. "Using Secure Sockets Layer (SSL)".
If you act as a CA, you can sign your own or anyone else's certificate request. This is a good choice if you only need the certificates within your private Web network and not for outside Internet commerce. Clients must have browsers, such as Secure WebExplorer and Netscape Navigator, that can receive your CA certificate and designate it as a a trusted root.
For example, if your company is working on a top secret project and you want to allow access only to a carefully controlled group of key people, you might want to issue them certificates so that they can share information covertly and safely.
If you choose to issue your own certificates, you will need to give the file that contains the signed certificate to users. They can then use read the certificate and designate it as an additional trusted root.
For more detailed step-by-step information on how to issue certificates, see Chapter 11. "Acting as a certification authority for a private Web network".
In order for the server to trust a request coming from a client, it must trust the CA that issued the client certificate. If you want to trust certificates coming from a CA other than the default trusted roots included with the server, you must receive a certificate from that CA and designate it as a trusted root.
With the remote configuration forms, you can:
You can access these trusted root functions from the Key Management form. To access this form:
Use the Designate Trusted Root Keys form to designate a trusted root key.
The current key ring file is displayed. To designate a trusted root key:
Select the key you want to designate as a trusted root. Do not designate keys as trusted root keys if you want the server to use them for secure communications. Trusted root keys cannot send or receive messages.
You may choose not to accept client requests from clients that have certificates issued by a specific CA.
Use the Remove Trusted Root Keys form to remove trusted root status from a key.
Note: This does not delete the key from your key ring file. See "Deleting a key" to delete a key.
The current key ring file is displayed. To remove trusted root status from a key:
Select the key you want to remove as a trusted root.