Oracle iPlanet Web Proxy Server 4.0.14 Administration Guide

Setting Security Preferences

Once you have a certificate, you can begin securing your server. 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 decrypting the data will be.

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.

You can specify which ciphers your server can use. Unless you have a compelling reason not to use a specific cipher, you should select them all. You might not wish to enable ciphers with less than optimal encryption.


Caution – 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.


Note –

In this scenario Proxy Server acts as SSL client and must have imported the root CA certificate which signs SSL server LDAP certificate. In case the SSL certificate for LDAP was not issued by a well known CA, the CA root key used must be imported to Proxy Server key store.


ProcedureTo enable LDAP with SSL connection 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 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 SSL Connection

Diagram showing an SSL connection from a client to a
secure server through the proxy server

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 process 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 used between the client and the remote server is SSL. Therefore 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 sites run the secure server on some other port, you can make explicit exceptions to allow connections to other ports on certain hosts by 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.

ProcedureTo 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 that does not exist outside of the proxy. See 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 Chapter 16, Managing Templates and Resources.

  4. Select Enable Proxying Of This Resource and click OK.


    Caution – Caution –

    If the proxy is misconfigured, 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. Therefore do not allow any more ports than absolutely necessary, and use access control on your proxy to restrict 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

The following example shows a successful response from the Proxy Server, followed by an empty line:

HTTP/1.0 200 Connection establishedProxy-agent: Oracle-iPlanet-Proxy-Server/4.0

The connection is then set up between the client and the remote server. 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 are automatically mapped into a URL such as this:

connect://energy.example.com:443

connect:// is an internal notation used by Proxy Server to make configuration easier and more uniform with other URL patterns. Outside of the Proxy Server, connect URLs do not exist. If the Proxy Server receives such a URL from the network, it marks the URL 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:


Note –

You can enable security only in reverse proxy mode and not in forward proxy mode.


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.

ProcedureTo 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. Provide the required information.


    Note –

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


  4. To turn security on, select Enabled from the Security drop-down list, and then click OK.

    If a server certificate has not been installed, your only choice will be Disabled. For more information about specific settings, see the online Help.

ProcedureTo 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. Select Enabled from the Security drop-down list, and click OK.

    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.


ProcedureTo 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. Select Enabled from the Security drop-down list, and click OK.

    If a server certificate has not been installed, your only choice will be Disabled.

  5. 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 the Proxy Server, 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 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.

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

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 SSL 2.0 protocol has known deficiencies, failing to detect “version rollback” attack attempts makes intercepting and decrypting encrypted connections easier for a third party.

ProcedureTo 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.

    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.

  4. 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 are formatted as : 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.

SSLSessionTimeout

The SSLSessionTimeout directive controls SSL 2.0 session caching. The syntax is:

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. The Syntax is:

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.

ProcedureTo 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 provide values for the following settings:

    • SSLSessionTimeout

    • SSLCacheEntries

    • SSL3SessionTimeout

    For more information about magnus.conf, see Oracle iPlanet Web Proxy Server 4.0.14 Configuration File Reference.