Sun Java logo     Previous      Contents      Index      Next     

Sun logo
Sun Java System Web Proxy Server 4.0.1 Administration Guide 

Chapter 5
Using Certificates and Keys

This chapter describes the use of certificates and keys authentication to secure Sun Java System Web Proxy Server. Proxy Server incorporates the security architecture of all Sun Java System servers, and is built on industry standards and public protocols for maximum interoperability and consistency.

This chapter assumes familiarity with the basic concepts of public-key cryptography, including encryption and decryption, public and private keys, digital certificates, and encryption protocols. For more information, see Introduction to SSL.

This chapter contains the following sections:


Certificate-based Authentication

Authentication is the process of confirming identity. In the context of network interactions, authentication is the confident identification of one party by another. Certificates are one way of supporting authentication.

A certificate consists of digital data that specifies the name of an individual, company, or other entity, and certifies that the public key included in the certificate belongs to that entity.

Both clients and servers can have certificates. Server authentication refers to the confident identification of a server by a client (identification of the organization assumed to be responsible for the server at a particular network address). Client authentication refers to the confident identification of a client by a server (identification of the person assumed to be using the client software). Clients can have multiple certificates, much like a person might have several different pieces of identification.

A certificate is issued and digitally signed by a Certificate Authority, or CA. The CA can be a company that sells certificates, or a department responsible for issuing certificates for your company’s intranet or extranet. You decide which CAs you trust enough to serve as verifiers of other people’s identities.

In addition to a public key and the name of the entity identified by the certificate, a certificate also includes an expiration date, the name of the CA that issued the certificate, and the digital signature of the issuing CA.

For more information regarding the content and format of a certificate, see Introduction to SSL.

For more information regarding supported certificate extensions, see All About Certificate Extensions.


Note

A server certificate must be installed before encryption can be activated.



Creating a Trust Database

Before requesting a server certificate you must create a trust database. In Proxy Server, the Administration Server and each server instance can have its own trust database. The trust database should only be created on your local computer.

When you create the trust database, you specify a password to be used for a key-pair file. You also need this password to start a server using encrypted communications. For a list of guidelines to consider when choosing a password, see Choosing Strong Passwords.

In the trust database you create and store the public and private keys, referred to as your key-pair file. The key-pair file is used for SSL encryption. You use the key-pair file when you request and install your server certificate. The certificate is stored in the trust database after installation.

The key-pair file is stored encrypted in the following directory:

server_root/alias/proxy-serverid-key3.db

The Administration Server can have only one trust database. Each server instance can have its own trust database.

To create a trust database
  1. Access either the Administration Server or the Server Manager and click the Security tab.
  2. Click the Create Database link.
  3. Enter a password for the trust database.
  4. Enter the password again and click OK.

Using password.conf

By default, the Proxy Server prompts the administrator for the key database password before starting up. To restart an unattended Proxy Server, you must save the password in a password.conf file. Do this only if your system is adequately protected, so that this file and the key databases are not compromised.

Typically, you cannot start a UNIX SSL-enabled server with the /etc/rc.local or the /etc/inittab files because the server requires a password before starting. Although you can start an SSL-enabled server automatically if you keep the password in plaintext in a file, this is not recommended. The server’s password.conf file should be owned by root or the user who installed the server, with only the owner having read and write access to the file.

On UNIX, leaving the SSL-enabled server's password in the password.conf file is a large security risk. Anyone who can access the file has access to the SSL-enabled server’s password. Consider the security risks before keeping the SSL-enabled server’s password in the password.conf file.

On Windows, if you have an NTFS file system, you should protect the directory that contains the password.conf file by restricting access, even if you do not use the file. The directory should have read and write permissions for the Administration Server user and the Proxy Server user. Protecting the directory prevents others from creating a false password.conf file. You cannot protect directories or files on FAT file systems by restricting access to them.

Starting an SSL-enabled Server Automatically

To start an SSL-enabled server automatically
  1. Make sure SSL is enabled.
  2. Create a new password.conf file in the config subdirectory of the Proxy Server instance.
    • If you are using the internal PKCS #11 software encryption module included with the Proxy Server, enter the following information:
      internal:your_ password
    • If you are using a different PKCS #11 module (for hardware encryption or hardware accelerators), specify the name of the PKCS #11 module, followed by the password. For example:
      nFast:your_ password

You will always be prompted to supply a password when starting the Proxy Server, even after the password.conf file has been created.


Requesting and Installing a VeriSign Certificate

VeriSign is Proxy Server’s preferred Certificate Authority. The company’s technology simplifies the certificate request process. VeriSign has the advantage of being able to return its certificate directly to your server.

After creating a certificate trust database for your server, you can request a certificate and submit it to a CA (Certificate Authority). If your company has its own internal CA, request your certificate from that department. If you plan to purchase your certificate from a commercial CA, choose a CA and ask for the specific format of the information they require.

The Administration Server can have only one server certificate. Each server instance can have its own server certificate.

This section contains the following topics:

Requesting a VeriSign Certificate

To request a VeriSign certificate
  1. Access either the Administration Server or the Server Manager and click the Security tab.
  2. Click the Request VeriSign Certificate link.
  3. Review the steps listed on the page that displays and click OK. The VeriSign Enrollment Wizard displays and walks you through the process.

Installing a VeriSign Certificate

To install a VeriSign certificate
  1. Access either the Administration Server or the Server Manager and click the Security tab.
  2. Click the Install VeriSign Certificate link.
  3. Unless you plan to use an external encryption module, select Internal from the Cryptographic Module drop-down list.
  4. Enter your key-pair file password or PIN.
  5. Select the Transaction ID to retrieve from the drop-down list and click OK.


Requesting and Installing Other Server Certificates

In addition to VeriSign, you can also request and install certificates from other Certificate Authorities. Your company or organization may provide its own internal certificates. This section describes how to request and install other types of server certificates.

This section contains the following topics:

Required CA Information

Before you start the request process, make sure you know what information your CA requires. The format of the requested information varies by CA, but you might typically be asked to provide the information listed below. Note that most of this information is usually not required for certificate renewals.

All information is combined as a series of attribute-value pairs called the distinguished name (DN), which uniquely identifies the subject of the certificate.

If you are purchasing your certificate from a commercial CA, you must contact the CA to find out what additional 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 they might ask whether you have the legal right to use the information you provide.

Some commercial CAs offer certificates with greater detail and veracity to organizations or individuals who provide more thorough identification. For example, you might be able to purchase a certificate stating that the CA has not only verified that you are the rightful administrator of the www.example.com computer, but that you are a company that has been in business for three years, and have no outstanding customer litigation.

Requesting Other Server Certificates

To request other server certificates
  1. Access either the Administration Server or the Server Manager and click the Security tab.
  2. Click the Request Certificate link.
  3. Specify if this is a new certificate or a certificate 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. Specify how you want to submit the request for the certificate:
    • To submit the request using e-mail, select CA Email Address and enter the appropriate e-mail address for such requests.
    • To submit the request using the CA’s web site, select CA URL and enter the appropriate URL for such requests.
  5. From the Cryptographic Module drop-down list, select the cryptographic module to be used for the key-pair file when requesting the certificate.
  6. Enter the password for your key-pair file. This is the password specified when you created the trust database, unless a cryptographic module other than Internal was selected. The server uses the password to obtain your private key and encrypt a message to the CA. The server then sends both your public key and the encrypted message to the CA. The CA uses the public key to decrypt your message.
  7. Enter your identification information, such as name and phone number. The format of this information varies by CA. Note that most of this information is usually not required for certificate renewals.
  8. Double-check your work to ensure accuracy, and then click OK. The more accurate the information, the faster your certificate is likely to be approved. If your request is going to a certificate server, you will be prompted to verify the form information before the request is submitted.

The server generates a certificate request that contains your information. The request has a digital signature created with your private key. The CA uses a digital signature to verify that the request was not tampered with during routing from your server computer to the CA. In the rare event that the request is tampered with, the CA usually contacts you by phone.

If you chose to e-mail the request, the server composes an e-mail message containing the request and sends the message to the CA. Typically, the certificate is then e-mailed to you. If you specified a URL to a certificate server, your server uses the URL to submit the request to the certificate server. You might get an e-mail response or a response by some other means, depending on the CA.

The CA notifies you if it agrees to issue you a certificate. In most cases, the CA sends your certificate using e-mail. If your organization is using a certificate server, you may be able to search for the certificate using the certificate server’s forms.


Note

Not everyone who requests a certificate from a commercial CA is given one. Many CAs require you to prove your identity before issuing a certificate. Also, it often can take anywhere from one day to several weeks to get approval. You are responsible for promptly providing all necessary information to the CA.


Install the certificate once you receive it. In the meantime, you can still use your Proxy Server without SSL.

Installing Other Server Certificates

When you receive your certificate from the CA, it is encrypted with your public key so that only you can decrypt it. Only by entering the correct password for your trust database can you decrypt and install your certificate.

There are three types of certificates:

A certificate chain is a hierarchical series of certificates signed by successive Certificate Authorities. A CA certificate identifies a Certificate Authority and is used to sign certificates issued by that authority. A CA certificate can in turn be signed by the CA certificate of a parent CA, and so on, up to a root CA.


Note

If your CA does not automatically send you its certificate, request it. Many CAs include their certificate in the e-mail with your certificate, and both certificates are installed by your server at the same time.


When you receive a certificate from the CA, it is encrypted with your public key so that only you can decrypt it. The Proxy Server uses the key-pair file password you specify to decrypt the certificate when it is installed. You can either save the e-mail somewhere accessible to the server, or copy the text of the e-mail and be ready to paste the text into the Install Certificate form, as described in the following procedure.

To install other server certificates
  1. Access either the Administration Server or the Server Manager and click the Security tab.
  2. Click the Install Certificate link.
  3. Next to Certificate For, select the type of certificate to install:
    • This Server
    • Server Certificate Chain
    • Certification Authority
    • For more information about specific settings, see the online Help.

  4. Select the cryptographic module from the drop-down list.
  5. Enter the key-pair file password.
  6. Enter a certificate name only if you selected Server Certificate Chain or Certification Authority in Step 3.
  7. Provide certificate information by doing one of the following:
    • Select Message Is In This File and then enter the full path name to the file that contains the CA certificate.
    • Select Message Text (with headers) and then copy and paste the contents of the CA certificate. Be sure to include the Begin Certificate and End Certificate headers, including the beginning and ending hyphens.
  8. Click OK.
  9. Select either:
    • Add Certificate if you are installing a new certificate.
    • Replace Certificate if you are installing a certificate renewal.

The certificate is stored in the server’s certificate database. For example:

server_root/alias/proxy-serverid-cert8.db


Migrating Certificates

When migrating from Sun ONE Web Proxy Server 3.6 (also known as iPlanet Web Proxy Server) to Sun Java System Web Proxy Server 4, your files, including your trust and certificate databases, are updated automatically.

Make sure that the Proxy Server 4 Administration Server has read permissions on the old 3.x database files. The files are alias-cert.db and alias-key.db, located in the 3.x_server_root/alias directory.

Key-pair files and certificates are migrated only if security is enabled for your server. You can also migrate keys and certificates by themselves using the Migrate 3.x Certificates option under the Security tab in the Administration Server and the Server Manager. For information about specific settings, see the online Help.

In previous versions, a certificate and key-pair file were referred to by an alias that could be used by multiple server instances. The Administration Server managed all of the aliases and their constituent certificates. In Sun Java System Web Proxy Server 4, the Administration Server and each server instance has its own certificate and key-pair file, referred to as a trust database instead of an alias.

The trust database and its constituent certificates are managed from the Administration Server for the Administration Server itself, and from the Server Manager for server instances. The certificate and key-pair database files are now named after the server instance that uses them. If, in the previous version, multiple server instances shared the same alias, when migrated the certificate and key-pair file are renamed for the new server instance.

The entire trust database associated with the server instance is migrated. All CAs listed in your previous database are migrated to the Proxy Server 4 database. If duplicate CAs occur, use the previous CA until it expires. Do not attempt to delete duplicate CAs.

Proxy Server 3.x certificates are migrated to the supported Network Security Services (NSS) format. The certificate is named according to the Proxy Server page from which it was accessed (that is, from the Administration Server Security tab or the Server Manager Security tab).

To migrate a certificate
  1. From your local computer, access either the Administration Server or the Server Manager and click the Security tab.
  2. Click the Migrate 3.x Certificates link.
  3. Specify the root directory where the 3.6 server is installed.
  4. Specify the alias for this computer.
  5. Enter the administrator’s password and click OK.

Using the Built-in Root Certificate Module

The dynamically loadable root certificate module included with Proxy Server contains the root certificates for many CAs, including VeriSign. The root certificate module allows you to upgrade your root certificates to newer versions in a much easier way. In the past you were required to delete the old root certificates one at a time, and then install the new ones, one at a time. To install well-known CA certificates, you can now simply update the root certificate module file to a newer version as it becomes available through future versions of the Proxy Server.

Because the root certificate is implemented as a PKCS #11 cryptographic module, you can never delete the root certificates it contains, and the option to delete will not be offered when managing these certificates. To remove the root certificates from your server instances, you can disable the root certificate module by deleting the following in the server’s alias file:

If later you want to restore the root certificate module, you can copy the extension from server_root/bin/proxy/lib (UNIX) or server_root\bin\proxy\bin (Windows) back into the alias subdirectory.

You can modify the trust information of the root certificates. The trust information is written to the certificate database for the server instance being edited, not back to the root certificate module itself.


Managing Certificates

You can view, delete, or edit the trust settings of the various certificates installed on your server. This includes your own certificate and certificates from CAs.

To manage certificates
  1. Access either the Administration Server or the Server Manager and click the Security tab.
  2. Click the Manage Certificates link.
    • If you are managing a certificate for a default configuration using the internal cryptographic module, a list of all installed certificates with their type and expiration date is displayed. All certificates are stored in the directory server_root/alias.
    • If you are using an external cryptographic module, such as a hardware accelerator, you must first enter your password for each specific module and click OK. The certificate list will update to include certificates in the module.
  3. Click the name of the certificate you want to manage. A page displays with management options for that type of certificate. Only CA certificates allow you to set or unset client trust. Some external cryptographic modules will not allow certificates to be deleted.
  4. Specify the desired action. The following options are available:
    • Delete certificate or Quit for certificates obtained internally
    • Set client trust, Unset server trust, or Quit for CA certificates

Certificate information includes the owner and who issued it. Trust settings allow you to set client trust or unset server trust. For LDAP server certificates, the server must be trusted.


Installing and Managing CRLs and CKLs

Certificate revocation lists (CRLs) and compromised key lists (CKLs) make known any certificates and keys that either client or server users should no longer trust. If data in a certificate changes, such as when a user changes offices or leaves the organization before the certificate expires, the certificate is revoked, and its data appears in a CRL. If a key is tampered with or otherwise compromised, the key and its data appear in a CKL. Both CRLs and CKLs are produced and periodically updated by a CA. Contact your specific CA to obtain these lists.

This section contains the following topics:

Installing CRLs or CKLs

To install CRLs or CKLs
  1. Obtain a CRL or CKL from your CA and download it to a local directory.
  2. Access either the Administration Server or the Server Manager and click the Security tab.
  3. Click the Install CRL/CKL link.
  4. Select either:
    • Certificate Revocation List
    • Compromised Key List
  5. Enter the full path name to the associated file and click OK. The Add Certificate Revocation List or Add Compromised Key List page displays, listing CRL or CKL information. If a CRL or CKL already exists in the database, a Replace Certificate Revocation List or Replace Compromised Key List page displays.
  6. Add or replace the CRL or CKL.

Managing CRLs and CKLs

To manage CRLs and CKLs
  1. Access either the Administration Server or the Server Manager and click the Security tab.
  2. Click the Manage CRL/CKL link. The Manage Certificate Revocation Lists /Compromised Key Lists page displays, listing all installed CRLs and CKLs and their expiration dates.
  3. Select a certificate from either the Server CRLs or Server CKLs list.
  4. Select Delete CRL or Delete CKL to delete the CRL or CKL, or Quit to return to the management page.


Setting Security Preferences

When you have a certificate, you can begin securing your server. Sun Java System Web Proxy Server provides many security elements, which are discussed in this section.

Encryption is the process of transforming information so it is unintelligible to anyone but the intended recipient. Decryption is the process of transforming encrypted information so that it is intelligible again. Proxy Server supports the Secure Sockets Layer (SSL) and Transport Layer Security (TLS) encryption protocols.

A cipher is a cryptographic algorithm (a mathematical function) used for encryption or decryption. SSL and TLS protocols contain numerous cipher suites. Some ciphers are stronger and more secure than others. Generally speaking, the more bits a cipher uses, the harder it is to decrypt the data.

In any two-way encryption process, both parties must use the same ciphers. Because a number of ciphers are available, you must enable your server for those most commonly used.

During a secure connection, the client and the server agree to use the strongest cipher they can both have for communication. You can choose ciphers from the SSL 2.0, SSL 3.0, and TLS protocols.


Note

Improvements to security and performance were made after SSL 2.0. Do not use SSL 2.0 unless you have clients that are incapable of using SSL 3.0. Client certificates are not guaranteed to work with SSL 2.0 ciphers.


The encryption process alone is not enough to secure your server’s confidential information. A key must be used with the encrypting cipher to produce the actual encrypted result, or to decrypt previously encrypted information. The encryption process uses two keys to achieve this result: a public key and a private key. Information encrypted with a public key can be decrypted only with the associated private key. The public key is published as part of a certificate. Only the associated private key is safeguarded.

For a description of the various cipher suites and more information about keys and certificates, see Introduction to SSL.

To specify which ciphers your server can use, select them in the list in the Proxy Server user interface. Unless you have a compelling reason not to use a specific cipher, you should select them all (although you may not wish to enable ciphers with less than optimal encryption).


Caution

Do not select Enable No Encryption, Only MD5 Authentication. If no other ciphers are available on the client side, the server defaults to this setting and no encryption occurs.


This section contains the following topics:

SSL and TLS Protocols

Proxy Server supports the SSL and TLS protocols for encrypted communication. SSL and TLS are application independent, and higher-level protocols can be layered transparently on them.

SSL and TLS protocols support a variety of ciphers used to authenticate the server and client to each other, transmit certificates, and establish session keys. Clients and servers may support different cipher suites, or sets of ciphers, depending on factors such as which protocol they support, company policies on encryption strength, and government restrictions on export of encrypted software. Among other functions, the SSL and TLS handshake protocols determine how the server and client negotiate which cipher suites they will use to communicate.

Using SSL to Communicate with LDAP

You should require your Administration Server to communicate with LDAP using SSL.

To enable SSL on your Administration Server
  1. Access the Administration Server and click the Global Settings tab.
  2. Click the Configure Directory Service link.
  3. In the table that displays, click the link for the directory service. The Configure Directory Service page displays. If the LDAP-based directory service has not yet been created, select LDAP Server from the Create New Service of Type drop-down list, and then click New to configure the directory service. For more information about the specific fields that display for an LDAP-based directory service, see the online Help.
  4. Select Yes to use SSL for connections, and then click Save Changes.

Tunneling SSL Through the Proxy Server

When you are running a Proxy Server (proxy) in the forward direction and a client requests an SSL connection to a secure server through the proxy, the proxy opens a connection to the secure server and then simply copies data in both directions without intervening in the secure transaction. This process is known as SSL tunneling, and is illustrated in the following figure.

Figure 5-1  With an SSL connection, the Proxy Server cannot view the data it transfers.

Figure showing SSL tunneling.

To use SSL tunneling with HTTPS URLs, the client must support both SSL and HTTPS. HTTPS is implemented using SSL with normal HTTP. Clients without HTTPS support can still access HTTPS documents using the Proxy Server’s HTTPS proxying capability.

SSL tunneling is a lower-level activity that does not affect the application level (HTTPS). SSL tunneling is just as secure as SSL without proxying. The existence of the proxy in between does not in any way compromise security or reduce the functionality of SSL.

With SSL, the data stream is encrypted, so the proxy has no access to the actual transaction. Consequently, the access log cannot list the status code or the header length received from the remote server. This also prevents the proxy, or any other third party, from eavesdropping on the transactions.

Because the proxy never sees the data, it cannot verify that the protocol spoken between the client and the remote server is SSL. This means the proxy also cannot prevent other protocols from being passed through. You should restrict SSL connections to only well-known SSL ports, namely port 443 for HTTPS and 563 for SNEWS, as assigned by the Internet Assigned Numbers Authority (IANA). If there are sites that run the secure server on some other port, you can make explicit exceptions to allow connections to other ports on certain hosts. This is done using the connect://.* resource.

The SSL tunneling capability is actually a general, SOCKS-like capability that is protocol independent, so you can also use this feature for other services. Proxy Server can handle SSL tunneling for any application with SSL support, not just the HTTPS and SNEWS protocols.

Configuring SSL Tunneling

The following procedure describes how to configure your Proxy Server to tunnel SSL.

To configure SSL tunneling
  1. Access the Server Manager for a server instance and click the Routing tab.
  2. Click the Enable/Disable Proxying link.
  3. Select the connect://.*.443 resource from the drop-down list. The connect:// method is an internal proxy notation and does not exist outside of the proxy. See the following description in Technical Details for SSL Tunneling for more information about connect. To allow connections to other ports, you can use similar URL patterns in a template. For more information about templates, see Managing Templates and Resources.
  4. Select Enable Proxying Of This Resource and click OK.


Caution

If the proxy is misconfigured, it is possible to abuse the SSL proxy to achieve telnet hopping. Someone can use the proxy to make it appear that a telnet connection is coming from the proxy host, rather than the actual connecting host. This is why you must allow no more ports than absolutely necessary, and use access control on your proxy (restricting the client hosts).


Technical Details for SSL Tunneling

Internally, SSL tunneling uses the CONNECT method with the destination host name and port number as a parameter followed by an empty line:

CONNECT energy.example.com:443 HTTP/1.0

A successful response from the Proxy Server would be the following, followed by an empty line:

HTTP/1.0 200 Connection established
Proxy-agent: Sun-Java-System-Web-Proxy-Server/4.0

The connection is then set up between the client and the remote server, and data can be transferred in both directions until either closes the connection.

Internally, to benefit from the typical configuration mechanism based on URL patterns, the host name and port number (energy.example.com:443) are automatically mapped into a URL such as this:

connect://energy.example.com:443

connect:// is only an internal notation used by Proxy Server to make configuration easier and uniform with other URL patterns. Outside of the Proxy Server, connect URLs do not exist, and if the Proxy Server receives such a URL from the network, it marks it as invalid and refuses to service the request.

Enabling Security for Listen Sockets

You can secure your server’s listen sockets by doing the following:

Turning Security On

You must turn security on before you can configure the other security settings for your listen socket. You can turn security on when you create a new listen socket or edit an existing one.

To turn security on when creating listen sockets
  1. Access either the Administration Server or the Server Manager and click the Preferences tab.
  2. Click the Add Listen Socket link.
  3. Enter the required information. To turn security on, select Enabled from the Security drop-down list, and then click OK. Note that if a server certificate has not been installed, your only choice will be Disabled. For more information about specific settings, see the online Help.

    Note

    Use the Edit Listen Sockets link to configure the security settings after a listen socket has been created.


To turn security on when editing listen sockets
  1. Access either the Administration Server or the Server Manager and click the Preferences tab.
  2. Click the Edit Listen Sockets link.
  3. Click the link for the listen socket you want to edit.
  4. To turn security on, select Enabled from the Security drop-down list, and then click OK. Note that if a server certificate has not been installed, your only choice will be Disabled.

Selecting Server Certificates for Listen Sockets

You can configure listen sockets in either the Administration Server or the Server Manager to use server certificates you have requested and installed.


Note

At least one certificate must be installed.


To select a server certificate for a listen socket
  1. Access either the Administration Server or the Server Manager and click the Preferences tab.
  2. Click the Edit Listen Sockets link.
  3. Click the link for the listen socket you want to edit.
  4. To turn security on, select Enabled from the Security drop-down list, and then click OK. Note that if a server certificate has not been installed, your only choice will be Disabled.
  5. After selecting Enabled and clicking OK, select a server certificate from the drop-down Server Certificate Name list for the listen socket, and then click OK.

Selecting Ciphers

To protect the security of your Proxy Servers, you should enable SSL. You can enable the SSL 2.0, SSL 3.0, and TLS encryption protocols and select the various cipher suites. The SSL and TLS protocols can be enabled on the listen socket for the Administration Server. Enabling SSL and TLS on a listen socket for the Server Manager sets those security preferences for specific server instances. At least one certificate must be installed.


Note

Enabling SSL on a listen socket applies only in a reverse proxy scenario. That is, only when the Proxy Server is configured to perform reverse proxying.


The default settings allow the most commonly used ciphers. Unless you have a compelling reason for not using a specific cipher suite, you should select them all. For more information regarding specific ciphers, see Introduction to SSL.

The default and recommended setting for TLS Rollback is Enabled. This configures the server to detect man-in-the-middle version rollback attack attempts. Setting this to Disabled may be required for interoperability with some clients that incorrectly implement the TLS specification.

Note that disabling TLS Rollback leaves connections vulnerable to version rollback attacks. Version rollback attacks are a mechanism by which a third party can force a client and server to communicate using an older, less secure protocol such as SSL 2.0. Because there are known deficiencies in the SSL 2.0 protocol, failing to detect version rollback attack attempts makes it easier for a third party to intercept and decrypt encrypted connections.

To enable SSL and TLS
  1. Access either the Administration Server or the Server Manager and click the Preferences tab.
  2. Click the Edit Listen Sockets link, and then click the link for the listen socket you want to edit. For a secure listen socket, the available cipher settings are displayed.

    Note

    If security is not enabled on the listen socket, no SSL and TLS information is listed. To work with ciphers, ensure that security is enabled on the selected listen socket. For more information, see Enabling Security for Listen Sockets.


  3. Select the checkboxes corresponding to the required encryption settings and click OK.

    Note

    Select both TLS and SSL 3.0 for Netscape Navigator 6.0. For TLS Rollback also select TLS, and make sure both SSL 3.0 and SSL 2.0 are disabled.


Once SSL has been enabled on a server, its URLs use https instead of http. URLs that point to documents on an SSL-enabled server have this format:

https://servername.domain.dom:port

For example, https://admin.example.com:443.

If you use the default secure HTTP port (443), you do not need to enter the port number in the URL.

Configuring Security Globally

Installing an SSL-enabled server creates directive entries in the magnus.conf file (the server’s main configuration file) for global security parameters.

To set values for SSL configuration file directives
  1. Access the Server Manager for a server instance.
  2. Ensure that security is enabled for the listen socket you want to configure. For more information, see Enabling Security for Listen Sockets.
  3. Manually edit the magnus.conf file and enter values for the following settings:
    • SSLSessionTimeout
    • SSLCacheEntries
    • SSL3SessionTimeout

These SSL configuration file directives are described below. For more information about magnus.conf, see the Proxy Server Configuration File Reference.

SSLSessionTimeout

The SSLSessionTimeout directive controls SSL 2.0 session caching.

Syntax

SSLSessionTimeout seconds

where seconds is the number of seconds until a cached SSL session becomes invalid. The default value is 100. If the SSLSessionTimeout directive is specified, the value of seconds is silently constrained to be between 5 and 100 seconds.

SSLCacheEntries

Specifies the number of SSL sessions that can be cached.

SSL3SessionTimeout

The SSL3SessionTimeout directive controls SSL 3.0 and TLS session caching.

Syntax

SSL3SessionTimeout seconds

where seconds is the number of seconds until a cached SSL 3.0 session becomes invalid. The default value is 86400 (24 hours). If the SSL3SessionTimeout directive is specified, the value of seconds is silently constrained to be between 5 and 86400 seconds.


Using External Encryption Modules

Proxy Server supports the following methods of using external cryptographic modules such as smart cards or token rings:

You must add the PKCS #11 module before activating the FIPS-140 encryption standard.

This section contains the following topics:

Installing the PKCS #11 Module

Proxy Server supports Public Key Cryptography Standard (PKCS) #11, which defines the interface used for communication between SSL and PKCS #11 modules. PKCS #11 modules are used for standards-based connectivity to SSL hardware accelerators. Imported certificates and keys for external hardware accelerators are stored in the secmod.db file, which is generated when the PKCS #11 module is installed. The file is located in the server_root/alias directory.

Using modutil to Install PKCS #11 Modules

You can install PKCS #11 modules in the form of .jar files or object files using the modutil tool.

To install PKCS #11 modules using modutil
  1. Make sure all servers, including the Administration Server, have been stopped.
  2. Go to the server_root/alias directory containing the databases.
  3. Add server_root/bin/proxy/admin/bin to your PATH.
  4. Locate modutil in server_root/bin/proxy/admin/bin.
  5. Set the environment. For example:
    • On UNIX: setenv
    • LD_LIBRARY_PATH server_root/bin/proxy/lib:${LD_LIBRARY_PATH}

    • On Windows, add it to the PATH

      LD_LIBRARY_PATH server_root/bin/proxy/bin

      You can find the PATH for your computer listed under: server_root/proxy-admserv/start.

  6. Enter the command: modutil. The options will be listed.
  7. Perform the actions required.
  8. For example, to add the PKCS #11 module in UNIX, enter:

    modutil -add (name of PKCS#11 file) -libfile (your libfile for PKCS #11) -nocertdb -dbdir . (your db directory)

Using pk12util

Using pk12util allows you to export certificates and keys from your internal database and import them into an internal or external PKCS #11 module. You can always export certificates and keys to your internal database, but most external tokens will not allow you to export certificates and keys. By default, pk12util uses certificate and key databases named cert8.db and key3.db.

Exporting with pk12util

To export a certificate and key from an internal database
  1. Go to the server_root/alias directory containing the databases.
  2. Add server_root/bin/proxy/admin/bin to your PATH.
  3. Locate pk12util in server_root/bin/proxy/admin/bin.
  4. Set the environment. For example:
    • On UNIX: setenv
    • LD_LIBRARY_PATH/server_root/bin/proxy/lib:${LD_LIBRARY_PATH}

    • On Windows, add it to the PATH
    • LD_LIBRARY_PATH server_root/bin/proxy/bin

      You can find the PATH for your computer listed under: server_root/proxy-admserv/start.

  5. Enter the command: pk12util. The options will be listed.
  6. Perform the actions required.
  7. For example, in UNIX enter:

    pk12util -o certpk12 -n Server-Cert [-d /server/alias] [-P https-test-host]

  8. Enter the database password.
  9. Enter the pkcs12 password.

Importing with pk12util

To import a certificate and key into an internal or external PKCS #11 module
  1. Go to the server_root/alias directory containing the databases.
  2. Add server_root/bin/proxy/admin/bin to your PATH.
  3. Locate pk12util in server_root/bin/proxy/admin/bin.
  4. Set the environment. For example:
    • On UNIX: setenv
    • LD_LIBRARY_PATH/server_root/bin/proxy/lib:${LD_LIBRARY_PATH}

    • On Windows, add it to the PATH
    • LD_LIBRARY_PATH server_root/bin/proxy/bin

      You can find the PATH for your computer listed under: server_root/proxy-admserv/start.

  5. Enter the command: pk12util. The options will be listed.
  6. Perform the actions required.
  7. For example, in UNIX enter:

    pk12util -i pk12_sunspot [-d certdir][-h “nCipher”][-P https-jones.redplanet.com-jones-]

    -P must follow the -h and be the last argument.

    Enter the exact token name including capital letters and spaces between quotation marks.

  8. Enter the database password.
  9. Enter the pkcs12 password.

Starting the Server with an External Certificate

If you install a certificate for your server into an external PKCS #11 module (for example, a hardware accelerator), the server will not be able to start using that certificate until you edit the server.xml file or specify the certificate name as described below.

The server always tries to start with the certificate named Server-Cert. However, certificates in external PKCS #11 modules include one of the module’s token names in their identifier. For example, a server certificate installed on an external smartcard reader called smartcard0 would be named smartcard0:Server-Cert.

To start a server with a certificate installed in an external module, you must specify the certificate name for the listen socket on which it runs.

Selecting the Certificate Name for a Listen Socket

To select the certificate name for a listen socket

If security is not enabled on the listen socket, certificate information will not be listed. To select a certificate name for a listen socket, you must first ensure that security is enabled on the listen socket. For more information, see Enabling Security for Listen Sockets.

  1. Access either the Administration Server or the Server Manager and click the Preferences tab.
  2. Click the Edit Listen Sockets link.
  3. Click the link for the listen socket you want to associate with a certificate.
  4. Select a server certificate from the Server Certificate Name drop-down list for the listen socket and click OK. The list contains all internal and external certificates installed.

You could also tell the server to start with that server certificate instead, by manually editing the server.xml file. Change the servercertnickname attribute in the SSLPARAMS to:

$TOKENNAME:Server-Cert

To find what value to use for$TOKENNAME, go to the server’s Security tab and select the Manage Certificates link. When you log in to the external module where Server-Cert is stored, its certificates are displayed in the list in the $TOKENNAME:$NICKNAME form.


Note

If you did not create a trust database, one will be created for you when you request or install a certificate for an external PKCS #11 module. The default database created has no password and cannot be accessed. Your external module will work, but you will not be able to request and install server certificates. If a default database has been created without a password, use the Create Database page on the Security tab to set the password.


FIPS-140 Standard

The PKCS #11 APIs enable communication with software or hardware modules that perform cryptographic operations. Once PKCS #11 is installed on your Proxy Server, you can configure the server to be FIPS-140 compliant (FIPS stands for Federal Information Processing Standards). These libraries are included only in SSL 3.0.

To enable FIPS-140
  1. Install the plug-in following the FIPS-140 instructions.
  2. Access either the Administration Server or the Server Manager and click the Preferences tab.
  3. Click the Edit Listen Sockets link. For a secure listen socket, the Edit Listen Sockets page displays the available security settings.

    Note

    To work with FIPS-140, ensure that security is enabled on the selected listen socket. For more information, see Enabling Security for Listen Sockets.


  4. Select Enabled from the SSL Version 3 drop-down list, if not already selected.
  5. Select the appropriate FIPS-140 cipher suite and click OK:
    • Enable Triple DES with 168 bit encryption and SHA authentication (FIPS)
    • Enable DES with 56 bit encryption and SHA authentication (FIPS)


Setting Client Security Requirements

After you have performed all of the steps to secure your servers, additional security requirements can be set for your clients.

Client authentication is not essential to an SSL connection, but it does give extra assurance that encrypted information is being sent to the correct parties. You can use client authentication in a reverse proxy to make sure that your content server does not share information with unauthorized proxies or clients.

This section contains the following topics:

Requiring Client Authentication

You can enable the listen sockets for your Administration Server and each server instance to require client authentication. When client authentication is enabled, the client’s certificate is required before the server sends a response to a query.

Proxy Server supports authenticating client certificates by matching the CA in the client certificate with a CA trusted for signing client certificates. You can view a list of CAs trusted for signing client certificates in the Manage Certificates page on the Security tabs.

You can configure the Proxy Server to refuse any client that does not have a client certificate from a trusted CA. To accept or reject trusted CAs, client trust must be set for the CA. For more information, see Managing Certificates.

Proxy Server logs an error, rejects the certificate, and returns a message to the client if the certificate has expired. You can also view which certificates have expired from the Manage Certificates page.

You can configure your server to gather information from the client certificate and match it with a user entry in an LDAP directory. This ensures that the client has a valid certificate and an entry in the LDAP directory. It can also ensure that the client certificate matches the one in the LDAP directory. To learn how to do this, Mapping Client Certificates to LDAP.

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 (ACLs). For more information, see Using Access Control Files.

To require client authentication
  1. Access either the Administration Server or the Server Manager and click the Preferences tab.
  2. Click the Edit Listen Sockets link.
  3. Click the link for the listen socket for which you are requiring client authentication.
  4. Use the Client Authentication drop-down list to require client authentication for the listen socket, and then click OK.

Client Authentication in a Reverse Proxy

In a reverse proxy, you can configure client authentication according to any one of the following scenarios:

For information about how to configure these scenarios, see Setting Up Client Authentication in a Reverse Proxy.

Setting Up Client Authentication in a Reverse Proxy

Client authentication in a secure reverse proxy provides further insurance that your connections are secure. The following instructions explain how to configure client authentication according to the scenario you choose.


Note

Each scenario assumes that you have both a secure Client-to-Proxy connection and a secure Proxy-to-Content-Server connection.


Proxy-Authenticates-Client

To configure the Proxy-Authenticates-Client scenario
  1. Follow the directions for configuring the secure Client-to-Proxy and secure Proxy-to-Content Server scenario in "Setting up a Reverse Proxy" in Using a Reverse Proxy.
  2. Access the Server Manager for a server instance and click the Preferences tab.
  3. Click the Edit Listen Sockets link, and then click the link for the desired listen socket in the table that displays. (Use the Add Listen Socket link to configure and add listen sockets.)
  4. Specify client authentication requirements:
  5. To permit access to all users with valid certificates:

    • In the Security section, use the Client Authentication setting to require client authentication on this listen socket. Note that if a server certificate has not been installed, this setting will not be visible.
    • To permit access to only those users who have both valid certificates and are specified as acceptable users in access control:

    • In the Security section, leave the Client Authentication setting set to off. Note that if a server certificate has not been installed, this setting will not be visible.
    • On the Server Manager Preferences tab for this server instance, click the Administer Access Control link.
    • Select an ACL, and then click the Edit button. The Access Control Rules For page displays (authenticate first, if prompted).
    • Turn access control on (select the Access control Is On checkbox if not already selected).
    • Set your Proxy Server to authenticate as a reverse proxy. For more information, see Setting up a Reverse Proxy.
    • Click the Rights link for the desired access control rule, specify access rights in the lower frame, and then click Update to update this entry.
    • Click the Users/Groups link. In the lower frame, specify users and groups, select SSL as the authentication method, and then click Update to update this entry.
    • Click Submit in the upper frame to save your entries.
    • For more information about setting access control, see Controlling Access to Your Server.

Content Server-Authenticates-Proxy

To configure the Content Server-Authenticates-Proxy scenario
  1. Follow the directions for configuring the secure Client-to-Proxy and secure Proxy-to-Content-Server scenario in Setting up a Reverse Proxy.
  2. On your content server, turn client authentication on.

  3. Note

    You can modify this scenario so that you have an unsecure client connection to the Proxy Server, a secure connection to the content server, and the content server authenticates the Proxy Server. To do so, you must turn encryption off and tell the proxy to initialize certificates only as described in the following procedure.


Proxy-Authenticates-Client and Content Server-Authenticates-Proxy

To configure the Proxy-Authenticates-Client and Content Server-Authenticates-Proxy scenario
  1. Follow the directions for configuring the Proxy-Authenticates-Client scenario in Proxy-Authenticates-Client.
  2. On your content server, turn client authentication on.

Mapping Client Certificates to LDAP

This section describes the process the Proxy Server uses to map a client certificate to an entry in an LDAP directory.

When the server receives a request from a client, it asks for the client’s certificate before proceeding. Some clients send the client certificate to the server along with the request.


Note

Before mapping client certificates to LDAP, you must also configure the required ACLs. For more information, see Controlling Access to Your Server.


The server tries to match the CA to the list of trusted CAs in the Administration Server. If there is no match, Proxy Server ends the connection. If there is a match, the server continues processing the request.

After verifying the certificate is from a trusted CA, the server maps the certificate to an LDAP entry by doing the following:

The server uses a certificate mapping file called certmap.conf to determine how the LDAP search is performed. The mapping file tells the server what values to take from the client certificate (such as the end user’s name, e-mail address, and so on). The server uses these values to search for a user entry in the LDAP directory, but first the server must determine where in the LDAP directory to start the search. The certificate mapping file also tells the server where to start.

Once the server knows where to start the search and what to search for (first point, above), it performs the search in the LDAP directory (second point). If it finds no matching entry or more than one matching entry, and the mapping is not set to verify the certificate, the search fails.

The following table lists the expected search result behavior. Note that you can specify the expected behavior in the ACL. For example, you can specify that the Proxy Server accepts only you if the certificate match fails. For more information about how to set the ACL preferences, see Using Access Control Files.

Table 5-1  LDAP Search Results

LDAP Search Result

Certificate Verification ON

Certificate Verification OFF

No entry found

Authentication fails

Authentication fails

Exactly one entry found

Authentication fails

Authentication succeeds

More than one entry found

Authentication fails

Authorization fails

After the server finds a matching entry and certificate in the LDAP directory, it can use that information to process the transaction. For example, some servers use certificate-to-LDAP mapping to determine access to a server.

Using the certmap.conf File

Certificate mapping determines how a server looks up a user entry in the LDAP directory. You can use certmap.conf to configure how a certificate, designated by name, is mapped to an LDAP entry. You edit this file and add entries to match the organization of your LDAP directory, and to list the certificates you want your users to have. Users can be authenticated based on user ID, e-mail, or any other value used in the subjectDN. Specifically, the mapping file defines the following information:

The certificate mapping file is found in the following location:

server_root/userdb/certmap.conf

The file contains one or more named mappings, each applying to a different CA. A mapping has the following syntax:

certmap name issuerDN
name
:property [value]

The first line specifies a name for the entry and the attributes that form the distinguished name found in the CA certificate. The name is arbitrary and can be defined to whatever you prefer. However, issuerDN must exactly match the issuer DN of the CA that issued the client certificate. For example, the following two issuer DN lines differ only in the spaces separating the attributes, but the server treats these two entries as different:

certmap sun1 ou=Sun Certificate Authority,o=Sun,c=US
certmap sun2 ou=Sun Certificate Authority, o=Sun, c=US


Tip

If you are using Sun Java System Directory Server and experiencing problems in matching the issuer DN, check the Directory Server error logs for useful information.


The second and subsequent lines in the named mapping match properties with values. The certmap.conf file has six default properties (you can use the certificate API to customize your own properties):

For more information about these properties, refer to the examples described in Sample Mappings.

Creating Custom Properties

The client certificate API can be used to create your own properties. Once you have a custom mapping, you reference the mapping as follows:

name:library path_to_shared_library
name
:InitFN name_of_init_function

For example:

certmap default1 o=Sun Microsystems, c=US
default1:library /usr/sun/userdb/plugin.so
default1:InitFn plugin_init_fn
default1:DNComps ou o c
default1:FilterComps l
default1:verifycert on

Sample Mappings

The certmap.conf file should have at least one entry. The following examples illustrate the different ways certmap.conf can be used.

Example #1

This example represents a certmap.conf file with only one default mapping:

certmap default default
default:DNComps ou, o, c
default:FilterComps e, uid
default:verifycert on

Using this example, the server starts its search at the LDAP branch point containing the entry ou=orgunit, o=org, c=country, where the italicized text is replaced with the values from the subject’s DN in the client certificate.

The server then uses the values for e-mail address and user ID from the certificate to search for a match in the LDAP directory. When an entry is found, the server verifies the certificate by comparing the one sent by the client to the one stored in the directory.

Example #2

The following example file has two mappings: one for default and another for the US Postal Service:

certmap default default
default:DNComps
default:FilterComps e, uid

certmap usps ou=United States Postal Service, o=usps, c=US
usps:DNComps ou,o,c
usps:FilterComps e
usps:verifycert on

When the server receives a certificate from anyone other than the US Postal Service, it uses the default mapping, which starts at the top of the LDAP tree and searches for an entry matching the client’s e-mail and user ID. If the certificate is from the US Postal Service, the server starts its search at the LDAP branch containing the organizational unit and searches for matching e-mail addresses. Also note that if the certificate is from the US Postal Service, the server verifies the certificate. Other certificates are not verified.


Caution

The issuer DN (that is, the CA’s information) in the certificate must be identical to the issuer DN listed in the first line of the mapping. In the previous example, a certificate from an issuer DN that is o=United States Postal Service,c=US will not match because there is not a space between the o and the c attributes.


Example #3

The following example uses the CmapLdapAttr property to search the LDAP database for an attribute called certSubjectDN, whose value exactly matches the entire subject DN taken from the client certificate.

certmap myco ou=My Company Inc, o=myco, c=US
myco:CmapLdapAttr certSubjectDN
myco:DNComps o, c
myco:FilterComps mail, uid
myco:verifycert on

If the client certificate subject is:

uid=Walt Whitman, o=LeavesOfGrass Inc, c=US

the server first searches for entries that contain the following information:

certSubjectDN=uid=Walt Whitman, o=LeavesOfGrass Inc, c=US

If one or more matching entries are found, the server proceeds to verify the entries. If no matching entries are found, the server uses DNComps and FilterComps to search for matching entries. In this example, the server searches for uid=Walt Whitman in all entries under o=LeavesOfGrass Inc, c=US.


Note

This example assumes the LDAP directory contains entries with the attribute certSubjectDN.



Setting Stronger Ciphers

The Set Cipher Size option on the Server Manager Preferences tab presents a choice of 168-, 128-, or 56-bit secret key size for access or no restriction. You can specify a file to be served when the restriction is not met. If no file is specified, Proxy Server returns a Forbidden status.

If you select a key size for access that is not consistent with the current cipher settings under Security Preferences, Proxy Server displays a popup dialog warning that you need to enable ciphers with larger secret key sizes.

The implementation of the key size restriction is based on an NSAPI PathCheck directive in obj.conf, rather than Service fn=key-toosmall. This directive is:

PathCheck fn="ssl-check" [secret-keysize=nbits] [bong-file=filename]

where nbits is the minimum number of bits required in the secret key, and filename is the name of a file to be served if the restriction is not met.

PathCheck returns REQ_NOACTION if SSL is not enabled, or if the secret-keysize parameter is not specified. If the secret key size for the current session is less than the specified secret-keysize, the function returns REQ_ABORTED with a status of PROTOCOL_FORBIDDEN if bong-file is not specified, or else REQ_PROCEED, and the path variable is set to the bong-file filename. Also, when a key size restriction is not met, the SSL session cache entry for the current session is invalidated, so that a full SSL handshake occurs the next time the same client connects to the server.


Note

The Set Cipher Size form removes any Service fn=key-toosmall directives found in an object when it adds a PathCheck fn=ssl-check.


To set stronger ciphers
  1. Access the Server Manager for a server instance and click the Preferences tab.
  2. Click the Set Cipher Size link.
  3. From the drop-down list, select the resource to which to apply stronger ciphers, and then click Select. You can also specify a regular expression. For more information, see Managing Templates and Resources.
  4. Select the secret key size restriction:
    • 168 bit or larger
    • 128 bit or larger
    • 56 bit or larger
    • No restrictions
  5. Specify the file location of the message to reject access, and click OK.

For more information about ciphers, see Introduction to SSL.


Other Security Considerations

Other security risks exist beyond someone trying to break your encryption. Networks face risks from external and internal hackers, using a variety of tactics to gain access to your server and the information on it. In addition to enabling encryption on your server, you should take extra security precautions. For example, put the server computer in a secure room, and do not allow individuals you do not trust to upload programs to your server. This section describes some of the key things you can do to make your server more secure.

This section contains the following topics:

Limiting Physical Access

This simple security measure is often forgotten. Keep the server computer in a locked room that only authorized people can enter. This prevents anyone from hacking the server computer itself. Also, protect your computer’s administrative (root) password, if you have one.

Limiting Administration Access

If you use remote configuration, be sure to set access control to allow administration from only a few users and computers. If you want your Administration Server to provide end-user access to the LDAP server or local directory information, consider maintaining two Administration Servers and using cluster management, so that the SSL-enabled Administration Server acts as the master server, and the other Administration Server is available for end-users’ access. For more information about clusters, see Managing Server Clusters.

You should also turn encryption on for the Administration Server. If you do not use an SSL connection for administration, be cautious when performing remote server administration over an unsecure network. Anyone could intercept your administrative password and reconfigure your servers.

Choosing Strong 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. Your private key password is the next most important. 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.

A good password is one you will remember but others will not guess. For example, you could remember MCi12!mo as "My Child is 12 months old!" An example of a bad password is your child’s name or birthday.

Creating Hard-to-Crack Passwords

Some simple guidelines will help you create a stronger password. It is not necessary to incorporate all of the following rules in one password, but the more rules you use, the better your chances of making your password hard to crack. Some tips:

Changing Passwords or PINs

It is a good practice to change your trust database/key-pair file password or PIN periodically. If your Administration Server is SSL-enabled, this password is required when starting the server. Changing your password periodically adds an extra level of server protection.

You should only change this password on your local computer. For a list of guidelines to consider when changing a password, see Creating Hard-to-Crack Passwords.

To change the trust database/key-pair file password
  1. Access either the Administration Server or the Server Manager and click the Security tab.
  2. Click the Change Key Pair File Password link.
  3. From the Cryptographic Module drop-down list, select the security token on which you want to change the password. By default, this is Internal for the internal key database. If PKCS #11 modules are installed, all of the security tokens will be listed.
  4. Enter your current password.
  5. Enter your new password.
  6. Enter it again and click OK.

Make sure your key-pair file is protected. The Administration Server stores key-pair files in the directory server_root/alias.

It is also important to know if the file is stored on backup tapes or otherwise available for someone to intercept. If so, you must protect your backups as completely as your server.

Limiting Other Applications on the Server

Carefully consider all applications that run on the same computer as the server. It is 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 UNIX sendmail daemon is difficult to configure securely and can be programmed to run other possibly detrimental programs on the server computer.

UNIX and Linux

Carefully choose the processes started from inittab and rc scripts. Do not run telnet or rlogin from the server computer. You also should not have rdist on the server computer. This can distribute files but can also be used to update files on the server computer.

Windows

Carefully consider which drives and directories you share with other computers. Also, consider which users have accounts or Guest privileges. Be careful about what programs you put on your server, or allow others to install. Other people’s programs might have security holes. Even worse, someone might upload a malicious program designed specifically to subvert your security. Always examine programs carefully before you allow them on your server.

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 an HTML file:

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

Limiting Ports

Disable any ports not used on the computer. 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 computer is to physically use the server’s computer, which should already be in a restricted area.

Knowing Your Server’s Limits

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

Being aware of these limitations helps you understand 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 computer? What happens to those numbers after the SSL connection is terminated? Be sure to secure any information clients send to you through SSL.



Previous      Contents      Index      Next     


Part No: 819-3650-10.   Copyright 2005 Sun Microsystems, Inc. All rights reserved.