Encryption and SSL

This chapter gives an overview of Internet and intranet security and privacy concerns. It also describes how the server uses state-of-the-art encryption technology to ensure privacy to clients connecting to it. Netscape servers use a communication system called Secure Sockets Layer (SSL) to ensure privacy when communicating with other SSL-enabled products, such as Netscape Navigator. Instructions on installing and enabling security features begin with "Enabling SSL on your server" on page 99.

The Internet is like an open book. Information that you send from one computer to another can pass through numerous other computers before it reaches its destination. Normally, the users of these intermediary computers don't monitor the Internet traffic that routes through them, but someone determined can intercept and eavesdrop on your private conversations or credit card exchanges. Worse still, they might replace your information with their own and send it back on its way. Due to the architecture of the Internet and intranets, there will always be ways for unscrupulous people to intercept and replace data in transit.

So is there any way to ensure privacy over the Internet? Thankfully, there is. You encrypt, or disguise, your information before you send it over the Internet. That way, if someone intercepts it, the data is meaningless, and impossible to change without the alteration being known to the intended recipient.

Internet security threats

Without security precautions, you might encounter three types of problems when you send information over the Internet or an intranet.

Internet security precautions

The Secure Sockets Layer (SSL) protocol used in Netscape products provides several features that safeguard against the threats listed previously.

Encryption

Encryption is the process of transforming information so it can't be decrypted or read by anyone but the intended recipient. This disguised information is called ciphertext. It is the ciphertext that you send across the Internet. For example, if you have a financial report stored at your web site. If SSL is enabled on your server, your server encrypts the report and sends the ciphertext to a client, who turns the ciphertext back into the financial report.

The encryption process looks like this:

The encryption process

Decryption reverses the process, turning the ciphertext back into the original message. The recipient is the only one who can do this because only the recipient has a key. This is at the heart of encryption: only someone with the correct key can "unlock" a message. (To see how encryption is able to resist "brute force" attacks by someone without the key, see "How does encryption work?" on page 90.)

In fact, both the encryption and the decryption processes require keys, and sometimes use the same key. Like a combination lock protecting a safe--the same combination is used to secure and retrieve something. This is known as symmetric encryption.

One problem with symmetric encryption is that anyone who uncovers the key can decrypt your messages, as well as encrypt new messages so they would appear as authentic as yours. This same person could edit or replace messages in transit from you to your intended recipient.

You can avoid this problem by using different keys for encryption and decryption. Then you would have a system like the one described in the following section.

Public-key encryption

In public-key encryption, you use two keys: one for encrypting data and the other for decrypting. The encryption key is called the public key, and the decryption key is the private key. Public-key encryption is one of the processes that the server uses to exchange data with clients. Here's how public-key encryption works with a server.

  1. Your server uses two keys, a public key and a private key.
  2. Your server sends your public key to any client that requests it.
  3. Any client can use your public key to create ciphertext that can be decrypted only by your matching private key. Conversely, if your server receives a client's public key, you could encrypt messages that only that client can decrypt. Public-key encryption can be represented like this:

Public-key encryption

As with any encryption process, as long as you actually keep your private key private, your encrypted messages are safe from tampering. Even an eavesdropper who gets both the public key and the ciphertext can't work backwards and discover either your private key or your original message. In Netscape servers and clients, you have the additional safeguard of password protection before your private key can be used by the application. Note that this is only required when you start your server, not every time a secure connection is requested by a client.

What keeps public-key encryption secure is that you never share your private key with anyone, so no one can ever decrypt your messages. If your private key is ever compromised, you must immediately create a new public/private key pair. (See "Generating a key pair" on page 100 for more information.)

Public-key encryption takes longer than symmetric encryption. However, client-server communication with SSL uses both types of encryption together to maximize their strengths. Here's how these processes are leveraged. A client and server exchange public keys, and then the client generates a symmetric encryption key that is used only for this transaction. This key is called a session key. The client encrypts the session key with the server's private key and sends it to the server. For the rest of that transaction, the client and the server can use the quicker symmetric encryption. (This is the basis of SSL, as discussed on page 95.)

Your server can perform encryption with a number of different encryption functions, called ciphers. (Refer to "Setting security preferences" on page 106 for more information.) Some ciphers are stronger--that is, more resistant to cracking--than others

During an SSL connection, the client and the server agree to use the strongest cipher they can both communicate with.

Signing files

Public-key encryption also allows you to create a message that anyone can decrypt, that can only have been created by you. You do this by simply reversing the use of the keys: you encrypt a message using your own private key--that way, anyone with your public key can decrypt it. Because only a message encrypted with your private key can be decrypted with your public key, that message is proven to be from you.

You can use this "proof of sender" feature of public key encryption in conjunction with the ability to guarantee message integrity. And you can do this without disguising the contents of a file. This process is called signing a file. When you sign a file, you guarantee message integrity as with normal encryption, but without forcing the recipient to decrypt the message to read it. If you were to look at a signed message, it would appear as a normal unencrypted message with a section of encrypted text after it. Even though the message itself isn't encrypted, you still run the decryption process on it to make sure that the digital signature matches the message. If the message has been changed since the file was signed, the signature will not decrypt correctly.

When you sign a file with your private key, you are sending out a public message, readable by anyone, that can be proven to be your note because it can only be decrypted with your public key. (File signing is used in SSL, as described on page 95.)

How does encryption work?

This section explains technically how encryption works. You don't need to know these facts to operate an SSL-enabled server, but if you want to know about the mathematical underpinnings of this system, this section will introduce them to you.

It might seem odd that you can give an eavesdropper both your public key and a sample of your ciphertext and still be sure that your original message and private key can't be discovered. This is the case, though. Here's why.

The encryption keys discussed in the previous sections are complex mathematical functions that are easy to compute in one direction, and extremely difficult to compute in the reverse. That is, it's easy for a computer to figure out the ciphertext when presented with the original message and the encryption key, but very difficult to figure out the original message, with only the ciphertext and the encryption key. Because all data stored in computers can ultimately be expressed numerically, you can perform mathematical functions on any information on your computer.

An example of a simple mathematical function is

	m+3=c
This is an easy equation to reverse. If you know c (the ciphertext), you can figure out m (the message). In fact, even if you kept this equation (that is, the key) secret, someone could figure it out relatively quickly by examining your ciphertext for patterns.

The types of functions used in public-key encryption are vastly more complex than the previous example. They are, also, resistant to pattern searches because they use prime numbers in their calculations. (A prime number is divisible only by itself and one.) The first ten prime numbers are 2, 3, 5, 7, 11, 13, 17, 19, 23, and 29. The number 6 is not prime, because it can also be divided by 2 and 3. There are no patterns for determining prime numbers, so if you use an encryption key that uses prime numbers in the right manner, examining the ciphertext for patterns does no good. In fact, the SSL protocol uses a number of different types of encryption keys throughout its sequence.

If it is next-to-impossible to determine the original message once it's in ciphertext, how is the private key holder able to uncover it? It's because the private key is also a complex mathematical function, one that is incorporated into the function of the public key as a built-in shortcut to "solving" the public key function (or turning the ciphertext back into the original message). And, even if someone gets your public key, it's as impossible to determine what that corresponding private key is as it is to determine the original message from the ciphertext and the public key.

How secure is encryption?

Technically, it's not impossible to "crack" ciphertext and determine the content of the original message--it just takes a lot of time and money. For example, to crack the 128-bit encryption of a single SSL message, it would take a single pentium-based computer a greater amount of time than the age of the Earth.

Of course, you could use several computers in conjunction. For example, if you dedicated 10 computers to cracking that same encryption, it would take you one-tenth the time. Even then, only the single message in question would be deciphered because SSL generates a new encryption key for every exchange. (For more details, see "Putting all the pieces together: SSL" on page 95.)

The precise level of security a key offers is measured by the size of certain numbers used in creating the key. These numbers are measured in bits. The greater the number of bits, the more secure the key. The key used in the previous paragraph's example is a 128-bit key, which is so strong that the United States government doesn't allow products containing it to be exported. International versions of Netscape products are limited to 40-bit encryption keys. This is still strong enough to stop most criminals. However, it is conceivable that someone could use 100 dedicated computers working together to crack it more quickly. Of course, the cost of making such powerful machines unavailable for other tasks for that amount of time would be very high indeed--probably millions dollars.Finally, keep in mind that new computing power tends to double every 18 months. The encryption that keeps you safe today may not hold up to cracking ten years from now.

When considering encryption, remember that the trade-off is the value of the information versus the cost or time to crack the encryption. If the information is worth less than what it would cost to crack the encryption protecting it, then you are probably safe. Still, it's always a good idea to use the strongest encryption possible. Inadequate encryption is like no encryption at all--arguably worse, since it lulls you into a false sense of security.

Now that security is increased when passing information back and forth, how can you be sure the recipient is who they claim to be? The same as in real life--you ask for identification, which is covered in the following section.

Authentication and certificates

Over the Internet and smaller internal intranets, identification takes the form of an authentication certificate, or simply, a certificate. It is a non-transferable, non-forgeable, digital file issued from a third party that both communicating parties already trust. This third party is known as a Certification Authority, or CA. You decide which CAs you trust enough to serve as verifiers of other people's identities. (This is described in "Choosing Certification Authorities" on page 95.)

Both clients and servers can have certificates. Also, they can have multiple certificates, much like a person might have several different pieces of identification. When a web site sends its certificate to a client, the process is called server authentication. When a client sends a certificate to a server, the process is called client authentication. The Netscape FastTrack Server supports server authentication. For example, if you visit a web site called www.danishfurniture.com, you might find it possesses a certificate issued from a company named CertSafe, assuring you that this site is the one true www.danishfurniture.com. If you trust CertSafe's judgment, then you can trust that www.danishfurniture.com is the site it claims to be.

When SSL is enabled, server authentication is accomplished with these steps.

  1. A client requests a connection with an SSL-enabled server.
  2. The server signs but does not encrypt its certificate and sends it to the client.
  3. The client uses the server's public key, which is included in the certificate file to verify that the owner of the certificate is the same one who signed it. See "Public-key encryption" on page 88 and "What's in a certificate file?" on page 94.
  4. The client checks whether the certificate's CA is one that it accepts. If so, the client proceeds to the next step; otherwise, the client program informs its user that this certificate was issued by an unknown CA.
  5. The client compares the information in the certificate with the information it just received about the server. If all the information matches, the client accepts the site as authenticated.
    Note
    Server authentication is not essential to an SSL connection--you can still exchange encrypted information--but it does give extra assurance to the client that they are sending encrypted information to the correct party. Also, although a client and server can communicate without authentication, if your server requires client authentication for access control, the client will be rejected. (See "Restricting access" on page 79 for more information.)

    Note
    As a client, you may find that your company might also have a department that functions as a CA for all internal communications. However, you might find that your company's certificate isn't accepted at any external sites you visit. In this case, you might want to purchase a certificate from an outside CA company. See "Choosing Certification Authorities" on page 95.

What's in a certificate file?

A certificate is merely a file that contains certain identifying information. The file is signed with the CA's private key to guarantee its authenticity and integrity. Netscape uses the industry standard certificate type, known as x.509v3, which contains the following information:

Choosing Certification Authorities

Certain CAs are automatically trusted by Netscape Navigator. If a server sends Navigator a certificate that uses an unknown CA, Navigator displays a dialog box notifying the user that he has received a certificate from an untrusted certification authority. Navigator 2.0 and later users can edit their list of trusted CAs. Use reputable CAs when you purchase your certificates.

Putting all the pieces together: SSL

Now that you have learned about the various technologies that provide confidentiality, integrity, and authentication, you'll see how all the pieces fit together to create the Secure Sockets Layer protocol, or SSL. Later in this chapter--starting on page 106--you'll learn the steps to take to create your server's public and private keys, and how to request and install a certificate.

Essentially, SSL is symmetric encryption nested within public-key encryption, authenticated through the use of certificates. An SSL connection can only occur between an SSL-enabled client and an SSL-enabled server. In fact, when a server is running in SSL mode, it can only communicate through SSL.

TCP/IP is Transmission Control Protocol/Internet Protocol, the basic language of the Internet, and HTTP is Hypertext Transfer Protocol, the basic language of the graphical World Wide Web, a subset of the Internet.
Technically speaking, SSL is a protocol that runs above TCP/IP and below HTTP or other top-level protocols. This is shown in the following figure.

How SSL relates to TCP/IP and application protocols.

An SSL connection is initiated by a web browser when it asks a server to send a document through the HTTPS protocol, rather than with HTTP. HTTPS is simply HTTP but with the extra SSL protocol steps taken before serving the document.

Here are the steps that make up SSL.

  1. The client sends a request (in the form https://servername.domain.com) to connect to the secure server.
  2. The server sends its pre-signed certificate to the client. This, and the first step, are collectively known as the handshake.
  3. The client checks if the certificate was issued by a CA it trusts. If so, it proceeds to the next step. Otherwise, the client can cancel the connection or proceed without authentication.
  4. The client compares the information in the certificate with the information it just received concerning the site: its domain name and its public key. If the information matches, the client accepts the site as authenticated.
  5. The client tells the server what ciphers, or types of encryption keys, it can communicate with.
  6. The server chooses the strongest common cipher and informs the client.
  7. Using that cipher, the client generates a session key (a symmetric encryption key to be used only for this transaction) and encrypts it using the server's public key.
  8. The client sends the encrypted session key to the server.
  9. The server receives the session key.
  10. The client and the server use the session key to encrypt and decrypt the data they send and receive. For the sake of clarity, some smaller steps were left out, but the overall structure of SSL communication is what's outlined above.

Increasing server security

There are other security risks besides someone trying to break your encryption. The modern network faces risk from external and internal hackers, using a variety of tactics to gain access to your server and the information on it.

So in addition to enabling SSL on your server, you should take extra security precautions. These safeguards range from putting the server machine itself into a secure room, to not allowing untrusted individuals to upload new programs to your server.

When considering how much extra security to implement, keep in mind that the strongest encryption in the world does you no good if someone can get to your data some other way. The following sections describe the most important things you can do to make your server more secure.

Limit physical access

This is probably the simplest security measure that is often forgotten. The server machine should be kept in a locked room that only authorized people have access to. This prevents anyone from hacking the server machine itself.

Also, make sure to limit knowledge of your machine's root password, if you have one.

Limit administration access

If you plan on remotely configuring your server, be sure to use your server's access control to allow administration from a very small number of locations. You should also make the administrative connection a mandatory SSL connection. If you don't use an SSL connection for administration, then you should never perform remote server administration over an unsecure network. Anyone could intercept your administrative password and reconfigure the server.

For more information on controlling administration access, see "Configuring your administration server" on page 35.

Choose good passwords

You use a number of passwords with your server--the administrative password, the private key password, database passwords, and so on. Your administrative password is the most important password of all, since anyone with that password can configure any and all servers on your computer. Most important after that is your private key password. If someone gets your private key and your private key password, they can create a fake server that appears to be yours, or intercept and change communications to and from your server.

For these reasons, it's very important that you choose passwords that are difficult to guess and that you never reveal them to anyone. Your most important passwords should never contain words from any language because numerous password-cracking programs exist that can run through millions of possible word combinations in seconds. Your important passwords also should be at least eight characters long, and contain a mix of upper- and lower-case letters, punctuation marks, or mathematical characters, and numerals.

A good password is one you'll remember but others won't guess. For example, MBi12!mo could be remembered as "My Baby is twelve months old!" A bad password would be your child's name or birthdate.

It's not a good idea to write your passwords anywhere, but if you feel you must, store them in a very safe place, perhaps even stored in a safe or other locked box that has limited access.

Secure your private key

Make sure your private key file is protected. Store the key file in a directory that only you or authorized administrators have access to. It's also important to know if the file is stored on backup tapes or is otherwise available for someone to intercept. If this is so, you must protect your backups with the same level of security that you protect your server.

Limit other applications on the server machine

Carefully consider all applications that run on the same machine as the server. It's possible to circumvent your server's security by exploiting holes in other programs running on your server. Disable all unnecessary programs and services. For example, the sendmail daemon is difficult to configure securely and it can be programmed to run other possibly detrimental programs on the server machine.

Carefully choose the processes started from initab and rc scripts. Don't run telnet or rlogin from the server machine. You also shouldn't have rdist on the server machine (this can distribute files but it can also be used to update files on the server machine).

Similarly, you should be very careful about what CGI, Java, and JavaScript programs you put on your server or allow other people to upload to your server. Other people's programs might have security holes. Worst of all, someone might upload a malicious program that is designed specifically to subvert your security. Always examine programs carefully before you allow them on your server.

Limit ports

Disable any ports not used on the machine. Use routers or firewall configurations to prevent incoming connections to anything other than the absolute minimum set of ports. This means that the only way to get a shell on the machine is to physically use the server's machine, which should be in a restricted area already.

Know your server's limits

The server offers secure connections between the server and the client. It can't control the security of information once the client has it, nor can it control access to the server machine itself and its directories and files.

Being aware of these limitations helps you know what situations to avoid. For example, you might acquire credit card numbers over an SSL connection, but are those numbers stored in a secure file on the server machine? What happens to those numbers after the SSL connection is terminated? You should be responsible for securing any information clients send to you through SSL.

Enabling SSL on your server

To enable SSL on your server, you must complete these four steps:

  1. Generate your server's key pair (public and private keys).
  2. Request a certificate from a Certification Authority, or CA
  3. Install the certificate the CA sends to you.
  4. Turn on SSL for your server.

Generating a key pair

For more information on public and private keys, see page 88 and page 95.
You need to generate a key-pair file that holds the public and private keys for your server. These keys are used during SSL communications. The private key is stored in encrypted form on the server machine using a password you specify.

  1. Log in as root.
  2. Change your directory to the server root.
  3. Run the key file generation program. It is in the bin directory of your server root. Type: bin/httpd/admin/bin/sec-key

  4. When prompted, type a location for the new key pair file. Usually, the key pair file is stored in the server root, under the directory httpd-[your server name]/config, with the name ServerKey.db.
  5. A screen with a progress meter appears. Type any random keys at different speeds until the progress meter is full. The time between each of your keystrokes will be used to create a create a unique key pair file.

  6. When prompted, type in a password for your key pair. Once you enable SSL, any time your server is restarted, you must type the password to decrypt the key file and extract the public and private keys. The password must be at least eight characters in length. It is required that the password have at least one non-alphabetical character (a number or punctuation mark) somewhere in the middle. Make sure you memorize this password. The security of your server is only as good as the security of the key file and its password.

  7. Retype the password and click OK.
  8. In the Server Manager, choose Encryption|Generate Key. The Generate a Key Pair File form appears.
  9. In the Key File Path field, type the path (relative to the server root directory) and file name of the key file. This directory should be safe from other users. For example, use a directory that only the server has read and write access to.
  10. Click OK. The server generates the key-pair file and places it in the directory you specified. You should continue enabling SSL by requesting a certificate, as discussed in the following section.

Changing your key pair file password

Note
You should periodically change your key file password. If you forget your password, you will have to regenerate your key-pair file. This means you must also obtain another certificate (there are usually additional costs to do this).

Warning!
Don't change your key file password if you are administering your server over a non-SSL connection. Anyone can intercept the information and activate or disable your SSL.

To change your key file password,

  1. In the Server Manager click Encryption|Change Key password. The Change Key Pair File Password form appears.
  2. Type the key file path and file name.
  3. Type the old password.
  4. Type the new password.
  5. Retype the new password.
  6. Click OK. Save and apply your changes.

Requesting a certificate

For information on what a certificate is, refer to "Authentication and certificates" on page 92.
After you generate a key pair, you can request a certificate from a Certification Authority, or CA. Note that not everyone who requests a certificate is given one. This is because many CAs require information proving your identity before they issue a certificate. Also, it can take anywhere from a day to two months or more to approve a certificate. You are responsible for promptly providing all the necessary information to the CA.

Before you request a certificate, you should choose a CA and contact them regarding the specific format of the information they require. (For more information on what some CAs require, see the next section.)

To request a certificate,

  1. In the Server Manager, choose Encryption|Request Certificate. The Request a Server Certificate form appears.
  2. In the Certificate Authority field, type the email address for the CA you have chosen.
  3. Specify if this is a new certificate or a renewal. Many certificates expire after a set period of time, such as six months or a year. Some CAs will automatically send you a renewal.
  4. Type the location and password for your key file. This information is not sent to the CA. The server uses this information to encrypt a message to the CA, and send the public key.
  5. Type your identification information. The format of this information varies by CA. For a general description of these fields, see the list in the next section. Most of this information usually isn't required for a renewal.
  6. Type your phone number. Be sure to include your area code and any international codes as applicable. The CA uses this number to contact you regarding your request for a certificate.
  7. Double-check your work to ensure accuracy. The more accurate the information, the faster your certificate is likely to be approved.
  8. Click OK when the information is correct. Save and apply your changes. The server composes an email to the CA that contains your information. The email has a digital signature created with your private key. The digital signature is used by the CA to verify that the email wasn't tampered with during routing from your server machine to the CA. In the rare event that the email is tampered with, the CA will usually contact you by phone.

    When the CA sends you your certificate via email, you can install it as discussed on page 104. In the meantime, you can still use your server without SSL. You should use this time to secure your machine (page 97), test CGI, API, or Java applications, or test your site's HTML.

What information does a CA need?

When you purchased the server, you received a list of CAs. You must contact a CA to find out what information they require before they issue a certificate. Most CAs require that you prove your identity. For example, they want to verify your company name and who is authorized by the company to administer the server and whether you have the legal right to use the information you provide.

When requesting a certificate, you provide the following to the CA:

Installing the certificate

When you receive your certificate via email from the CA, it will be encrypted with your public key so that only you can decrypt it. The server will decrypt it when you install it. You can either save the email somewhere accessible to the server or copy the text of the email and be ready to paste the text into the Install Certificate form, as described below.

To install the certificate,

  1. In the Server Manager, choose Encryption|Install Certificate.
  2. Either type the full path name to the saved email, or paste the email text in the space provided.
  3. In the Certificate Path field, specify a destination directory for the certificate. Enter the name as a relative path off your server directory. The default name and location is [ServerRoot]/https-443/ServerCert. Remember where you put this file! It should not appear in your document root directory or any generally available directory.

  4. Click OK. Save and apply your changes. The server decrypts the message, extracts the certificate, and saves it to the directory you specified. At this point, you can activate SSL for your server (see the next section), or specify the strength and type of encryption to use (see page 108).

Managing server certificates

You can install multiple certificates on your server. At any time, you can view your list of installed certificates, and delete any of them.

To view your current server certificates,

  1. In the Server Manager, choose Encryption|Manage Certificates. The Manage Server Certificates form appears.
  2. All installed certificates are listed, along side their types and expiration dates.
  3. To refresh the list of certificates, click the Refresh button.
  4. To delete a certificate or view more information about it, click its name. The Information For Certificate form appears, containing information about that certificate.
  5. To delete the certificate, click the Delete button. To return to the Server Manager, click the Quit button.

Activating SSL

After your certificate is installed, you can activate SSL for your server.

  1. In the Server Manager, choose Encryption|On/Off. The Encryption On/Off form appears.
  2. Click the On button.
  3. Type the port number you want your server to use, if it's different from the one you specified upon setup. Note that the standard port is 443. If you choose another port, clients will have to explicitly specify it in when they type your URL, as in https://www.danishfurniture.com:80.
  4. Enter the location of your server's keyfile as a relative path off your server directory. For more information, see "Generating a key pair" on page 100.
  5. Enter the location of your server's certificate file as a relative path off your server directory. For more information, see "Installing the certificate" on page 104.
  6. Click OK. Save and apply your changes.
    Note
    Most of the time, you want your server to run with SSL enabled. You might, at other times, want to disable it. If you temporarily disable SSL, make sure you re-enable it before processing transactions that require confidentiality, authentication, or data integrity.

    Now that SSL is enabled on your server, you can configure your overall SSL preferences (page 106), and specify different strengths of encryption for different parts of your server (page 108).

Setting security preferences

You can set a number of system-wide preferences for SSL. To do so, choose Encryption|Security Preferences in the Server Manager. After you make your changes, you must click OK and confirm your changes. You can configure the following settings.

SSL version. You can specify which versions of SSL your server can communication with. The latest and most secure version is SSL version 3, but many older clients use only SSL version 2. You will probably want to enable your server to use both versions.

Ciphers. A cipher is the algorithm used in encryption. Some ciphers are more secure or stronger than others. Generally speaking, the more bits a cipher uses during encryption, the harder it is to decrypt the data. (For a more complete discussion of algorithms and their strength, see "How secure is encryption?" on page 91.) This list doesn't appear unless you've installed security.

When a client initiates an SSL connection with a server, it lets the server know what ciphers it prefers to use to encrypt information. In any two-way encryption process, both parties must use the same ciphers. Since there are a number of ciphers available, your server needs to be able to use the most popular ones.

You can choose ciphers from the SSL 2 protocol, as well as from SSL 3. To specify which ciphers your server can use, check them in the list. Unless you have a compelling reason why you don't want to use a specific cipher, you should check them all.

Warning!
You might not want to check No Encryption, only MD5 message authentication. If no other ciphers are available on the client side, the server will use this, and no encryption will occur.

Another reason you might not want to enable all ciphers is to prevent SSL connections with less than optimal encryption. That is, United States law prohibits the export of products with 128-bit encryption, so overseas clients might only be using 40-bit encryption, which is not as difficult to crack as 128-bit. Unchecking all 40-bit ciphers effectively restricts access to browsers available only in the United States.

The SSL 2.0 ciphers are:

Specifying stronger encryption strength

You can specify settings for encryption strength for specified files or directories on your server. To do so, follow these steps.

  1. In the Server Manager, choose Encryption|Stronger Ciphers. The "Enforce Strong Security Requirements" form appears.
  2. Choose the resource to apply the stronger ciphers to. As discussed in the previous section, you might want to make any or all of your server accessible to only those clients who have ultra-strong encryption available.
  3. Choose the minimum cipher size allowed to connect to that resource.
  4. Click OK and confirm your changes.

Keeping clients from caching SSL files

Pre-encrypted files can be prevented from being cached on the client-side by adding the following line inside the head statement of a file in HTML:

	<meta http-equiv="pragma" content="no-cache">

Effects of an SSL-enabled server

You need to keep a few things in mind once SSL is enabled. This section describes what effects you need to know about while running an SSL-enabled server.

Secure URL construction

URLs to an SSL-enabled server are constructed using https instead of simply http. URLs that point to documents on an SSL-enabled server have the format:

https://[servername].[domain].[dom]/[pathname]/[document]

Secure server document root and logging

Once SSL is installed and enabled on a server, all communications between the server and SSL-enabled browsers (such as Netscape Navigator) are private, authenticated, and checked for message integrity. This means that any document sent to a user with an SSL-enabled browser is automatically encrypted. The only way around this is discussed in "Setting security preferences" on page 106.

Note
Browsers not enabled with SSL can't communicate with an SSL-enabled server because they can't enter an SSL transaction. However, they can communicate with the server when the server isn't using SSL.)

The secure log

Once SSL is enabled, a new log file, (secure.log) is created in the normal log directory. Entries in the log look like:

198.93.92.99: [02/Nov/1994:23:51:46 -0800] using keysize 40
where the IP address is first, followed by the date and time of access, and then the key size. The key size represents a level of security. Generally, the bigger the key size, the higher the level of security. See page 107 for a list of supported key sizes.

Unprotected server document directory

If you want to have both secure and unsecure servers, you should operate the unsecure server on a different machine from the secure server. If your resources are limited and you must run an unsecure server on the same machine as your secure server follow these guidelines.

Changes to the magnus.conf file

With an SSL-enabled server installed, there are several changes to the magnus.conf file (the server's main configuration file). These new directives are briefly described below:

Security

The Security directive tells the server whether SSL is enabled or disabled.

Syntax
Security value

value specifies if SSL is on or off. Security on enables SSL; Security off disables SSL.

SSL2

The SSL2 directive tells the server that SSL2 is enabled or disabled

Syntax
SSL2 value

value specifies if SSL version 2 is enabled or disabled. SSL2 on enables SSL 2. SSL2 off disables SSL 2.

SSL3

The SSL3 directive tells the server that SSL3 is enabled or disabled

Syntax
SSL3 value

value specifies if SSL version 3 is enabled or disabled. SSL3 on enables SSL 3. SSL3 off disables SSL 3.

ServerKey

The ServerKey directive tells the server where the key file is located.

Syntax
ServerKey keyfile

keyfile is the server's key file, specified as a relative path from the server root or as an absolute path.

ServerCert

The ServerCert directive specifies where the certificate file is located.

Syntax
ServerCert certfile

certfile is the server's certificate file, specified as a relative path from the server root or as an absolute path.

Ciphers

The Ciphers directive specifies the ciphers enabled for your server. For a discussion of the pros and cons of these ciphers, refer to "Setting security preferences" on page 106.

Syntax
Ciphers +rc4 +rc4export -rc2 -rc2export +idea +des +desede3

A + means the cipher is active, and a - means the cipher is inactive. Any cipher with export as part of its name is not stronger than 40 bits.

SSL3Ciphers

The SSL3Ciphers directive specifies the SSL 3 ciphers enabled for your server. For a discussion of the pros and cons of these ciphers, refer to "Setting security preferences" on page 106.

Syntax
SSL3Ciphers +rsa_rc4_128_md5 +rsa_3des_sha +rsa_des_sha +rsa_rc4_40_md5 +rsa_rc2_40_md5 -rsa_null_md5

A + means the cipher is active, and a - means the cipher is inactive. Any cipher with 40 as part of its name is 40 bits.

Further reading

The following resources will give you a broad view of the many different issues and perspectives concerning Internet security and encryption.