Using encryption and SSL

etscape servers use an encryption system called Secure Sockets Layer (SSL) to ensure privacy when communicating with other SSL-enabled products, such as Netscape Navigator and Netscape Communicator.

 For a complete discussion of encryption and SSL, see Managing Netscape Servers.

  

What is encryption?

Encryption is the process of transforming information so it can't be decrypted or read by anyone except the intended recipient. This encrypted information is called ciphertext. It is the ciphertext that you send across the network. For example, suppose 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 then decrypts the ciphertext back into the financial report.

Decryption reverses the process, turning the ciphertext back into the original message. Only the recipient can decrypt the text because only the recipient has the key. In fact, both the encryption and the decryption processes require keys.

Client-server communication with SSL uses two keys. The encryption key is called the public key, and the decryption key is the private key. SSL uses the two keys as follows:

• A client and server exchange public keys.


• 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 public key and sends it to the server.


• For the rest of that transaction, the client and server can use the same key for encryption and decryption.

 

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. The following list describes the most important things you can do to make your server more secure. For more information on server security see Managing Netscape Servers.

• Limit physical access. Keep the server machine in a locked room that only authorized people can enter. This prevents anyone from hacking the server machine itself.


• Limit administration access. If you plan on remotely configuring your server, be sure to use your administration 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.


• Choose good passwords. It's important to choose passwords that are difficult to guess and never to reveal them to anyone. Your most important passwords should not 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 uppercase and lowercase letters, punctuation marks, mathematical symbols, or numerals.


• 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 whether the file is stored on backup tapes or is otherwise available for someone to intercept. If so, you must protect your backups as much as you protect your server.


• Limit other applications on the server. It's possible to circumvent your server's security by exploiting holes in other programs running on your server. Therefore, it is wise to disable all unnecessary programs and services. Some applications that you should be cautious of are the sendmail daemon, telnet, rlogin, and rdist. Also be careful about which CGI, Java, and JavaScript programs are on your server.


• Limit ports. Disable extraneous services operating on ports for the machine. Use routers or firewall configurations to prevent incoming connections from accessing services available on different ports.


• Know your server's limits. A server can't control the security of information once it reaches the client, nor can it control which individuals have access to directories and files on the server. Therefore, it is your responsibility to secure any information clients send to you through SSL.

 

Preventing clients from caching SSL files

You can prevent pre-encrypted files from being cached by a client by adding the following line inside the <HEAD> section of a file in HTML:

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

 

Enabling SSL on your server

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

1. Generate your server's key-pair file (public and private keys). For more information on key pairs, see Managing Netscape Servers.


2. Request a certificate from a Certification Authority (CA). For more information on Certification Authorities, see Managing Netscape Servers.


3. Install the certificate the CA sends to you.


4. Turn on SSL encryption for your server.

Note

Steps 1 through 3 must be done through the administration server. For more information about using the administration server to enable SSL, see Managing Netscape Servers.

 

Activating SSL

After you have generated a key-pair file and installed your certificate, you can activate SSL for your server.

1. In the Server Manager, choose Server Preferences|Encryption On/Off. The Encryption On/Off form appears.


2. Check the On radio 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 specify it when they type your URL, as in https://www.mozilla.com:80.


4. From the alias drop-down list, select the name of the alias that you want to use for encryption. This alias maps to the key-pair file and certificate file you associated it with in the administration server.


5. 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. See "Setting encryption preferences" on page 135 for information on configuring encryption preferences for your server.

 

Setting encryption preferences

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

  

SSL version

You can specify which versions of SSL your server can communicate with. The latest and most secure version is SSL version 3, but many older clients use only SSL version 2. You need to have at least one version of SSL enabled for your server to function properly. You will probably want to enable your server to use both versions of SSL, however, if you want your server to only use one SSL version, you must enable both versions and disable all of the ciphers for the version you do not want to use.

  

Client certificates

You can configure the web server so that it refuses any client who doesn't have a client certificate from a trusted CA. This differs from access control in that all requests must be through SSL connections and they must be from clients who have certificates from trusted CAs. (See Managing Netscape Servers for details on configuring trusted CAs.)

 With client certificates on, the server asks the client to send its certificate before the server will grant the request. The server doesn't care who the user is as long as that user has a valid certificate from a trusted CA. However, you can combine client certificates with access control so that in addition to being from a trusted CA, the user associated with the certificate must match the access-control rules. See Chapter 6, "Controlling access to your server," for more information.

 To enable client authentication using trusted certificates:

1. Using the administration server, install a server certificate so that the web server can use SSL encryption, and then trust the CAs whose certificates you want to allow. The server will grant requests only to clients that have a certificate from a trusted CA.


2. Go to the Server Manager for the web server and choose Server Preferences|Encryption Preferences.


3. In the form that appears, choose Yes to require client certificates, and then click OK.


4. Turn on SSL for the web server. Save and apply your changes, and then restart the server.

If a user accessing the server doesn't have a certificate from a trusted CA, the server returns an error stating, "The server cannot verify your certificate." The server logs an error, but it doesn't list the untrusted CA. If you want to know which CA issued the certificate to the client, you need to use access control in addition to client authentication. With access control and certificate mapping, the server will log an error that lists the CA's distinguished name.

  

Ciphers

A cipher is an 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. The list of available ciphers doesn't appear on the Encryption Preferences form unless you've enabled SSL.

 When initiating an SSL connection with a server, a client lets the server know what ciphers it prefers for encrypting information. In any two-way encryption process, both parties must use the same ciphers. Because a number of ciphers are 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 not to use a specific cipher, you should check them all.

Another reason for not enabling all ciphers is to prevent SSL connections with less than optimal encryption. International versions of Netscape products are limited to 40-bit encryption keys. Therefore, international clients might be using only 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.

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. Also, by checking the "No encryption..." checkbox, only SHA message authentication sends data in the clear.

The SSL 2.0 ciphers are:

• RC4 cipher with 128-bit encryption and MD5 message authentication. RC4 ciphers are the fastest ciphers. This cipher, because it has 128-bit encryption, is the second strongest cipher next to Triple DES (Data Encryption Standard) with 168-bit encryption. It has approximately 3.4 * 10³⁸ possible keys, making it very difficult to crack. As added security, all SSL 2.0 ciphers use MD5 (Message Digest 5) message authentication. MD5 message authentication detects attempts to modify data while it is in transit.


• RC4 cipher with 40-bit encryption and MD5 message authentication. This cipher is also an RC4 cipher, making it one of the fastest available ciphers. It has 40-bit encryption, which has approximately 1.1 * 10¹² (a trillion) possible keys, making it easier to crack than encryption with more possible keys, such as 128-bit encryption. 40-bit encryption is the strongest encryption that Netscape Communications is permitted to export under U.S. law. This cipher also uses MD5 message authentication to detect attempts to modify data in transit.


• RC2 cipher with 128-bit encryption and MD5 message authentication. The RC2 ciphers are slower than the RC4 ciphers. This RC2 cipher, because it has 128-bit encryption, is the second strongest cipher next to Triple DES with 168-bit. It has approximately 3.4 * 10³⁸ possible keys, making it very difficult to crack. This cipher also uses MD5 message authentication to detect attempts to modify data in transit.


• RC2 cipher with 40-bit encryption and MD5 message authentication. This cipher is also an RC2 cipher, making it is slower than the RC4 cipher. It has 40-bit encryption, which is not as strong as 168-bit, 128-bit, or 56-bit encryption. 40-bit encryption has approximately 1.1 * 10¹² (a trillion) possible keys. This cipher also uses MD5 message authentication to detect attempts to modify data in transit.


• DES with 56-bit encryption and MD5 message authentication. DES (Data Encryption Standard) is a U.S. government standard for data encryption. This cipher does not have as many possible keys as does 128-bit encryption, and therefore is not as strong. 56-bit encryption has approximately 7.2 * 10¹⁶ possible keys. This cipher also uses MD5 message authentication to detect attempts to modify data in transit.


• Triple DES with 168-bit encryption and MD5 message authentication. Triple DES is the strongest cipher available, but it is not as fast as RC4. Triple DES uses a key three times as long as the key for standard DES. Because the key size is so large, there are more possible keys than for any other cipher - approximately 3.7 * 10⁵⁰. This cipher also uses MD5 message authentication to detect attempts to modify data in transit.

The SSL 3.0 ciphers are:

• RC4 with 128-bit encryption and MD5 message authentication. This cipher is the same as the SSL 2.0 version of RC4 with 128-bit encryption but uses a more secure implementation of MD5 message authentication to detect attempts to modify data in transit.


• RC4 with 40-bit encryption and MD5 message authentication. This cipher is the same as the SSL 2.0 version of RC4 with 40-bit encryption but uses a more secure implementation of MD5 message authentication to detect attempts to modify data in transit.


• Triple DES with 168-bit encryption and SHA message authentication. This cipher is the same as the SSL 2.0 version of Triple DES with 168-bit encryption, but uses SHA (Secure Hash Algorithm) message authentication instead of MD5 message authentication. SHA is a government standardized algorithm that is used to construct a message authentication code that detects attempts to modify data while it is in transit. SHA is slower than MD5, but it is stronger.


• DES with 56-bit encryption and SHA message authentication. This cipher is the same as the SSL 2.0 version of DES with 56-bit encryption but uses SHA message authentication instead of MD5 message authentication.


• RC2 with 40-bit encryption and MD5 message authentication. This cipher is the same as the SSL 2.0 version of RC2 with 40-bit encryption but uses a more secure implementation of MD5 message authentication to detect attempts to modify data in transit


• No encryption, only MD5 message authentication. This cipher uses only MD5 message authentication to secure data. Any data sent using this cipher is not encrypted. The data may be protected from modification, but it can be viewed by eavesdroppers.

 

Specifying stronger encryption ciphers

You can specify cipher bit size for specific files or directories on your server. That is, for users to access a resource, they must have a browser that supports the specific cipher size you specify for that resource.

Note

This feature is only available in the U.S. domestic version of Netscape Enterprise Server.

 To specify a cipher for a resource:

1. In the Server Manager, choose Server Preferences|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 strong encryption ciphers available.


3. Choose the minimum cipher size allowed to connect to the resource you picked.


4. Click OK and confirm your changes. Restart your server for the changes to take affect.

 

Effects of an SSL-enabled server

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 this format:

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

 

Secure server document root

After 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. Thus, any document sent to a user with an SSL-enabled browser is automatically encrypted.
 

Note

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

 

Unprotected server document directory

If you want to have both protected and unprotected servers, you should operate the unprotected server on a different machine from the protected one. If your resources are limited and you must run an unprotected server on the same machine as your protected server, do the following.

• Assign proper port numbers. Make sure that the protected server and the unprotected server are assigned different port numbers. The registered default port numbers are 443 for the protected server and 80 for the unprotected one.


• Enable the chroot feature for the document root directory. The unprotected server should have references to its document root redirected using the chroot feature.

 

Changes to the magnus.conf file

Installing an SSL-enabled server creates new directive entries in the magnus.conf file (the server's main configuration file). These new directives are briefly described in the following sections.

 

Security

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

Syntax

Security value

value specifies if SSL is on or off. Set the value parameter to on to enable SSL; and to off to disable SSL.

 

SSL2

The SSL2 directive tells the server whether SSL2 is enabled or disabled.
 

Syntax

SSL2 value

value specifies whether SSL version 2 is enabled or disabled. Set the value parameter to on to enable SSL 2 and to off to disable SSL 2.

 

SSL3

The SSL3 directive tells the server whether SSL3 is enabled or disabled.
 

Syntax

SSL3 value

value specifies whether SSL version 3 is enabled or disabled. Set the value parameter to on to enable SSL 3, and to off to disable SSL 3.

 

KeyFile

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

Syntax

KeyFile keyfile

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

 

CertFile

The CertFile directive specifies where the certificate file is located.

Syntax

CertFile certfile

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

 

Ciphers

The Ciphers directive specifies the ciphers enabled for your server. For a discussion of these ciphers, refer to "Setting encryption preferences" on page 135.
 

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 which SSL 3 ciphers are enabled for your server. For a discussion of these ciphers, refer to "Setting encryption preferences" on page 135.
 

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.

 

SSLClientAuth

The SSLClientAuth directive specifies whether a client must have a certificate in order to communicate with the server. You don't need to turn on this directive to use client authentication with access control.

Syntax

SSLClientAuth value

value specifies if certificates are always required. Set the value parameter to on to require certificates, and to off to specify that certificates are not required.

---

Copyright 1997 Netscape Communications Corporation. All rights reserved.