Ensuring a secure messaging system

This chapter provides information about security features available in Netscape Messaging Server 3.0. The chapter is divided into two sections:

• System security
• Encryption and security forms

System security

The messaging server approach to system security is to carefully isolate the messaging server from the remainder of the system. During messaging server installation, a special account is created for the Messaging Server to operate under. The account's permissions are intentionally limited to those necessary to operate the messaging server. The majority of executable modules that constitute the messaging server are designed to operate in this intentionally limited environment.

Runtime permissions

With few exceptions (discussed later), the daemon, or service, portion of the messaging server is the only module allowed to use root permissions during runtime. Most messaging server executables are run under the MTA user account and group and cannot gain access to the host system beyond what is required for the messaging system.

The messaging server daemon, or service, known as the dispatcher, is the module that controls the overall operation of the messaging system, as well as permissions for the other messaging server modules. Because the dispatcher's main role is to manage mail delivery, it doesn't actually communicate with users or other machines.

Unix

The dispatcher initially runs with root (or superuser) permissions when the messaging server is started so that it can initialize the network connections. Unix allows only a process with the root permissions to open and bind to a socket with a port number below 1024. The ports necessary for SMTP and POP3, for example, are 25 and 110, respectively, and thus root permission is required for those services.

Immediately following necessary initialization, and prior to accepting or processing any messages, the dispatcher irrevocably releases the root permission and hence takes only the permissions set up for the messaging server system during installation.

Thus, all special privileges are dropped, and only the MTA user's privileges are retained during normal operation. With few exceptions, the dispatcher runs all the messaging server modules with these limited permissions.

Note

The exception to the rule of limited permissions is the utility module that works with Unix Deliver to create a maildrop file. Because of the ownership requirements of the Unix maildrop file--the owner is the person receiving the incoming mail, and the group is usually the mail group--there must be a special program that can create an empty file with the proper permissions to allow access for both the mail system (to deposit mail) and the user (to pick up mail from the file). This module is therefore owned by root and has root permissions.

In normal operation, the messaging server uses three directory trees: the executable, postoffice, and mailbox directories. The permissions for each of these directory trees allow proper operation of the messaging server modules while providing a secure envelope for the host system running the messaging server.

The owner and group on these directories are as follows:

Access domains

An access domain restricts the places from which users can read their email. (The access domains are applied to the POP or IMAP mail client's hostname or IP address.)

Access can be limited to a single computer or a set of computers in an addressing hierarchy. You can specify a single computer by giving either its IP address or its fully qualified domain name (for example, sunnyvale.dispatch.com). Likewise, you can specify a set of computers by using an incomplete DNS or IP address. An incomplete DNS address is one that doesn't specify a particular host; an incomplete IP address is one that contains a 0, which acts as a wildcard, in any of the four numbers in the dotted quad address.

You can leave the access domain feature blank to allow access from anywhere (with the appropriate password), or you can enter the keyword "none" to prevent access to an account.

If a single computer is specified as the access domain--for instance, sunnyvale.dispatch.com--a user can't access mail from any other machine even when giving the correct password. If, instead, the access domain is specified as dispatch.com, the user can access his or her mail from any computer within the dispatch.com domain.

Use of domain names or IP addresses is a trade-off between flexibility and security. Using a hostname or domain name is easily understandable and immune to network topology changes, while an IP address or range might not be. Generally, IP addresses are safer than domain names as access domains. For maximum security, you can configure your access domain to be the IP address of a single computer.

Here's how an access domain might be set up:

  sunnyvale.dispatch.com
  128.123.45.0
  math.csusj.edu

The domain entries would let you access the account from any of these computers:

  sunnyvale.dispatch.com
  complex.math.csusj.edu
  fourier.math.csusj.edu

The IP entry would allow access from these hosts:

  128.123.45.22
  128.123.45.67
  128.123.45.82

However, you would not be able to access the account from these:

  newark.dispatch.com
  laser.ece.csusj.edu
  128.123.46.22
  128.124.45.67

Access domain algorithm

This section describes the steps that the messaging server follows when it verifies and limits access domains during POP/IMAP logins.

When a client connects to your machine, the messaging server is given the IP address of the connecting computer. The algorithm used to determine if the client computer can access the server is as follows:

1. If the list is empty, access is allowed.
   
2. If the list contains the keyword "none," access is denied.
   
3. For each IP address or network in the list (for example, 123.4.5.67), the messaging server checks for a match with the client's IP address. Any zero is treated as a wildcard match, so 123.4.5.0 would allow any computer in the 123.4.5 class-C network to connect. If a match is found, access is allowed. (No addresses are looked up in the DNS when performing this step--the numbers are simply compared. Also note that a host file can be consulted instead of the DNS if your machine is configured to do so.)
   
4. For each domain name in the list, the messaging server checks if the hostname associated with the client's IP address is within the domain (the client's hostname is found by using the DNS or the host file). For example, if the client's hostname is determined to be rome.dispatch.com, the connection is allowed if rome.dispatch.com, dispatch.com, or com is in the list of access domains. If a match is found, access is allowed.
   
5. If no match is found, access is denied.
   

If the user's login name and password are valid, and the above check succeeds relative to the user's access domains, then the user's POP or IMAP login is successful.

Encryption forms

The Messaging Server provides two forms that you can use for added security--the IMAP Encryption form and the Security Preferences form.

The IMAP Encryption and Authentication form

This form lets you specify the level of encryption and authentication for receiving and managing messages with IMAP clients. Choose the encryption and authentication options that provide adequate security for your needs.

The IMAP Encryption form provides three options for encryption using Secure Sockets Layer (SSL):

• Allow unencrypted access only
• Allow encrypted access only
• Allow both encrypted and unencrypted access

For authentications your options are:

• Use passwords only
• Use certificates only
• Use either passwords or certificates

The Encrypted port number field lets you specify a specific port for sending and receiving encrypted messages. The default is 220.

The Alias field provides a pull-down list of encryption aliases. Aliases are provided in the menu only if you have already created or imported them using the Administration Server's Generate Key or Import Alias forms. (For more information, see Chapter 4, "Understanding Encryption and SSL," in Managing Netscape Servers.)

The Security Preferences form

You can use the Security Preferences form to configure access domains for web form configuration.

1. Choose SSL version 3.
   

Although the form presents SSL version 2 as an option, there are no IMAP clients that communicate over SSL with that version.

2. Choose the ciphers you want your server to use.
   

The ciphers are listed for each version of SSL. 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. Ciphers are described after this list.

3. Click OK.

Make sure you restart your server. When a browser initiates an SSL connection with the Messaging 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 a number of ciphers are available, you should consider enabling all ciphers.

You can choose ciphers from both the SSL 2 and SSL 3 protocols. Unless you have a compelling reason why you don't want to use a specific cipher, you should choose them all--except for the "No Encryption, only MD5 message authentication" option, as it does not protect data from eavesdropping. Unless there is a compelling reason to use it, this cipher should not be enabled.

Warning!

If no other ciphers are available in the browser, the server will use the "No Encryption, only MD5 message authentication" option, and no encryption will occur.

The SSL 2.0 ciphers are:

• RC4 cipher with 40-bit encryption: This cipher is an RC4 cipher, which means that it is the fastest available cipher. It has 40-bit encryption, which is the strongest encryption Netscape is permitted to export under U.S. law. Forty-bit encryption has approximately 1.1 * 1012 (a trillion) possible keys.
• RC2 cipher with 40-bit encryption: This cipher is an RC2 cipher, which means that it is slower than the RC4 cipher. It has 40-bit encryption, which is the strongest encryption permitted for export under U.S. law. Forty-bit encryption is not as strong as 128-bit encryption, and has approximately 1.1 * 1012 (a trillion) possible keys.

The SSL 3.0 ciphers are:

• 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 MD5 message authentication to detect attempts to modify data in transit.
• 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 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 sent in the clear. The data may be protected from modification, but it can be viewed by eavesdroppers.

Copyright © 1999 Netscape Communications Corporation.
This site powered by: Netscape Enterprise Server and Netscape Compass Server.