Understanding security

his chapter describes some of the concepts behind authenticated and encrypted server communications.

Authentication verifies the identity of the client or server.

Encryption ensures that data cannot be deciphered if it is intercepted during transmission or if it is received by the wrong parties.

The Netscape Collabra Server uses an advanced protocol called Secure Sockets Layer (SSL) for transferring private data over TCP/IP networks. SSL ensures privacy when communicating with other SSL-enabled products, such as Netscape Navigator, Netscape Communicator, and other SSL-enabled news servers.

This chapter provides a general overview of SSL, authentication, and encryption. More details can be found in the administration server documentation, Managing Netscape Servers.

If you are already familiar with SSL, authentication, and encryption, and you only want to know how to enable SSL for your server, you can skip the overview material. See "Enabling SSL on your server" instead.

The SSL protocol runs as a network protocol above the TCP/IP layer and below the NNTP application layer, as shown in Figure 6.1.

How SSL relates to TCP/IP and application protocols

For purposes of the following discussions, security refers to the process of encrypting data before it is transmitted over a network. A server running in secure connection mode means that encryption is turned on for all incoming connections.

Of course there are other security risks besides someone trying to break your encryption. Along with encryption, you can take other steps to add security to your server. See "Increasing server security" for more information about these steps.

Understanding the need for security

Without security, there are three types of problems you might run into when sending sensitive information over a network:

• Eavesdropping, where your information remains intact, but its privacy is compromised. Some examples include someone spying on a private conversation, or intercepting classified information.

• Modification, where your original information is changed or replaced and then sent to the recipient, who is none the wiser. An example is someone altering an order for goods, or changing a person's resume in route to the recipient.

• Impersonation, where your information passes to the recipient, but the recipient is an imposter.

Understanding the features of SSL

• Confidentiality is ensured through encryption, the process of disguising information so that it can't be deciphered (or decrypted) by anyone other than the intended recipient. The information can still be intercepted, but it will be unreadable to third parties.

• Data integrity verifies that the data sent between client and server wasn't altered during transfer. If the message does not decrypt correctly, the recipient can tell that someone has tampered with the message.

• Authentication is provided through authenticity certificates, which are very difficult to falsify. You purchase or otherwise receive a certificate from a third party whom both parties already trust. In this way, the certificate acts as a sort of digital passport.

When an SSL-enabled client and server first start communicating, they agree on a protocol version, select encryption algorithms, optionally authenticate each other, and use encryption techniques to generate shared information.

The following sections provide a high-level overview of encryption and authentication and how they work together in SSL. For a more detailed discussion, see Managing Netscape Servers.

Encryption

SSL uses a method called public-key encryption, as shown in Figure 6.2:

Public-key encryption

In public-key encryption, you use two keys: one for encrypting data and the other for decrypting data. 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 your server could encrypt messages that only the client can decrypt.

If anyone ever obtains your private key, you must immediately create a new public/private key pair.

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 private key--and anyone with your public key can decrypt it. Because no one can create a message with your private key, the 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. 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.

Authentication by certificate

This certificate is issued from a third party whom both parties in communication already trust. This third party is known as a Certification Authority, or CA. The file is signed with the CA's private key to guarantee its authenticity and integrity.

Both servers and clients can have certificates. When a server sends a 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, as shown in Figure 6.3:

Server authentication and client authentication

The dotted line indicates that client authentication occurs only if the server requests a certificate from the client.

You need a certificate and a key to perform encryption. SSL does not require that both client and server are properly authenticated, but it will warn you if proper authentication does not occur. Thus, server and client authentication are not essential to an SSL connection--you can exchange encrypted information without authentication--but it does give extra assurance to the newsreader or remote server that they are sending encrypted information to the correct party.

Server certificates

If you plan on using encryption and SSL on your server, you must obtain a server certificate issued from a valid CA. See "Enabling SSL on your server" for more information.

In the following description of the server authentication process, a client can be:

• A newsreader, such as the Netscape Communicator Collabra client, connecting to a Collabra Server.

  When a newsreader connects to a news server, the server certificate identifies the news server to the newsreader. The newsreader is assured that it is connecting to the correct news server.

• A news server connecting to a remote news server to send encrypted data.

  When a news server connects to a remote news server to send encrypted information, the remote server sends its certificate to the sending server to identify itself before the sending server starts the encrypted transmissions.

1. A client sends a request to connect to an SSL-enabled server.

2. The server sends its certificate and its public key to the client.

3. The client checks if the server 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 server authentication. (If the client is another news server, the client will cancel.)

4. The client compares the information in the certificate with the information it just received concerning the server site: the server's domain name and its public key. If the information matches, the client accepts the server site as authenticated. (At this point, the server might request a certificate from the client. If so, the client must authenticate to the server.)

5. The client generates a session key (a key to be used only for this transaction) and encrypts it using the server's public key.

6. The client sends the encrypted session key to the server.

7. The server receives the session key and decrypts it using the server's private key.

8. The client and the server use the session key to encrypt and decrypt the data they send and receive.

When a newsreader attempts to connect to your Collabra Server, the server can request that the newsreader authenticate by sending a certificate. SSL is required to transfer the client certificate, so both the client and the server must be SSL-enabled. (SSL version 3 is required for client certificates.)

Client certificates provide more secure authentication than user name and password authentication. Only machines with a valid certificate signed by an authority that you trust can authenticate to your server.

If you are requiring that newsreaders use a certificate to authenticate to your Collabra Server:

1. The newsreader must obtain a certificate issued from a "trusted" CA (see step 3).

2. Your server must be running in secure connection mode. (The server can ask for the certificate only when running in secure-connection mode; that is, when encryption is turned on.)

3. Your server must indicate that it trusts the CA. You perform this step from the administration server interface. For more information see the administration server online documentation or the printed manual, Managing Netscape Servers.

4. Your server must map the certificate to a unique LDAP entry. For more information, see the administration server online documentation or the printed manual, Managing Netscape Servers.

5. If you are using the local directory service, you will need to modify the certmap.conf file as follows. You should read the information about configuring the certmap.conf file found in the administration server documentation first.
   • Set the value for the DNComps property to empty list (because the Collabra Server does not use the Base DN for the local directory service)

   • Set the value for the FilterComps property to Common Name, Email, or both

The following steps provide a general overview of SSL communication and the client authentication process:

1. A newsreader sends a request to connect to your Collabra Server.

2. The server sends its server certificate and its public key to the newsreader.

3. After the server authenticates to the newsreader, the server requests that the newsreader authenticate by sending a certificate to the server.

4. The newsreader sends a certificate and its public key to the server.

5. The server uses the newsreader's public key, which is included in the certificate file to verify that the owner of the certificate is the same one who signed the certificate.

6. The server checks whether the certificate's CA is one that the server trusts. If so, the server proceeds to the next step; otherwise, the server informs the client that the client certificate was issued by an unknown CA.

7. The server compares the information in the certificate with the information it just received about the newsreader. If all the information matches, the server accepts the newsreader as authenticated.

8. The newsreader generates a session key (a key to be used only for this transaction) and encrypts it using the server's public key.

9. The newsreader sends the encrypted session key to the server.

10. The server receives the session key and decrypts it using the server's private key.

11. The newsreader and the server use the session key to encrypt and decrypt the data they send and receive.

1. Generate your server's key pair (public and private keys)

2. Choose a Certification Authority (CA)

3. Request a certificate from a CA

4. Install the certificate the CA sends to you

5. Activate connection security

After you have performed steps 1 through 4, you can activate connection security by choosing Encryption|Activate Connection Security. For more information, see Chapter 2, "Activating connection security."

The encryption setting affects your incoming connections only. If you specify that encryption is on, then your server will receive encrypted data only.

You must specify that encryption is on if:

• You want to receive encrypted data

• You want to replicate discussion groups with remote servers running in secure connection mode

• You are requiring that clients use certificate authentication to connect to your server

If you are running the Collabra Server in secure connection mode, all communications between your server and SSL-enabled browsers (such as Netscape Navigator and Netscape Communicator) are private and server authenticated. Newsreaders without SSL support cannot connect to your Collabra Server.

Secure connection mode, however, does not prevent you from sending articles to other news servers that are not running in secure connection mode. For more information about server-to-server communication, see Chapter 5, "Managing replication of articles."

If you decide to run your Collabra Server in secure connection mode, there are a few other things to keep in mind regarding:

• URL construction

• Article storage

• Replication with other news servers

news://servername/discussion-group

snews://servername/discussion-group 

news://servername:563

See "Increasing server security" for more information about securing your machine.

Replication with other news servers

When you set up secure replication with remote servers, you should trust the sites you send to. After the articles have transferred, they are only as secure as the machine on which they are stored.

Because Usenet newsfeeds run nonsecure server software, you cannot receive Usenet news if your server is running in secure connection mode. However, you can install two instances of the Netscape Collabra Server: one instance running in secure connection mode, and the other instance running in nonsecure connection mode. This lets you receive Usenet news on the server running in nonsecure connection mode, and still maintain a secure environment for your confidential discussion groups.

If you do decide to run two servers on the same machine, one running in secure connection mode and one running in nonsecure connection mode, you must remember to:

• Assign different port numbers to the servers. For example, use 563 for the server running in secure connection mode and 119 for the server running in nonsecure connection mode.

• Use access control on both servers.

• Store discussion groups for the two servers in different spool directories; otherwise the servers will not function properly.

Increasing server security

So in addition to enabling SSL on your server, you can take other steps to add extra security to your server. These safeguards range from putting the server computer into a secure room, to not allowing untrusted individuals to upload new programs to your server.

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

• Limit physical access to the server

• Enable access control

• Limit administration access to the server

• Choose good passwords and change them frequently

• Secure your private key

• Limit applications running on your server

• Limit ports used by the server

• Use firewalls

Enable access control

Limit administration access

You should never do remote server administration over a nonsecure network. Anyone could intercept your administrative password and reconfigure the server.

Choose good passwords

Your administrative password is the most important password of all, since anyone with this password can reconfigure your entire server. Most important after that is your private key password. If someone steals your private key and discovers your private key password, they can appear to be you when sending messages or entering into SSL transactions.

For these reasons, it is very important that you choose passwords that are difficult to guess, and that you never reveal them to anyone. Additionally, your most important passwords should not contain words from any language, since numerous password-cracking programs exist. Your important passwords should be at least eight characters long, and contain a mix of uppercase and lowercase letters, punctuation or mathematical characters, and numerals.

As an added security, you should change your passwords frequently if you are able to do so.

Caution: The password used by the Collabra Server to access the Directory Server is stored in plain text in the nsnews.conf file.

Protect your private key

Limit applications

Similarly, you should be careful about what Java and JavaScript programs you allow other people to upload to your server. Other people's programs may have security holes that they don't know about. Worst of all, someone might upload a malicious program that is designed specifically to subvert your security.

Limit ports

Use firewalls

You can use firewalls to protect internal servers from outside access, as shown in Figure 6.4.

Using a firewall

The discussion groups that are for internal use only reside on a Collabra Server that sits behind the company firewall; thus the server is protected from outside access. The server is not running in secure connection mode because communications within the company do not require encryption.

The discussion groups that are replicated with servers outside your organization reside on a Collabra Server that runs on a firewall machine. This Collabra Server runs in secure connection mode so that data can be encrypted before it is transmitted over the external network.