iTP Secure WebServer System Administrator's Guide (iTPWebSvr 6.0+)

Configuring for Secure Transport

iTP Secure WebServer System Administrator’s Guide—523346-002

4-30

Controlling Encryption and Integrity Checking

The iTP Secure WebServer allows the web client and server to negotiate which

encryption algorithm will be used. The encryption algorithm is called a cipher. The

choice of cipher controls both the encryption and integrity checking required between

client and server.

Encryption protects the privacy of a message in transit, while integrity checking

provides proof that a message has not been altered during transit.

Using Ciphers With the AcceptSecureTransport Directive

The iTP Secure WebServer allows you to specify the ciphers that you want the

WebServer to support. Specifying a particular cipher mode ensures the maximum

security for each connection.

Encryption and integrity checking are controlled through the AcceptSecureTransport

directive’s -ciphers argument. Refer to AcceptSecureTransport on page A-5 for

details about the syntax and use of the -ciphers argument.

In general, your selection of the ciphers depends on your use of the iTP Secure

WebServer. For example, for financial transactions and private personal data, the

cipher Triple DES increases the amount of security. For basic level privacy, RC4

generally provides enough security while optimizing for speed.

Hashing Ciphers Used by iTP Secure WebServer Ciphers

The ciphers for secure transport ports within the iTP Secure WebServer can use two

different hashing algorithms. The first, called MD5, has been in wide use for many

years in various Internet applications. The other, called Secure Hash Algorithm

(SHA1), was developed by the U.S. government. For most applications, either cipher

provides sufficient security.

Negotiating Selection Among Available Ciphers

Use the -ciphers option to specify a Tcl list of ciphers that describe the bulk encryption

and hash algorithms the iTP Secure WebServer will use. If you specify no

-ciphers option, all the ciphers are set by default.

The cipher negotiated for the connection will be the first cipher on the web client’s list

supported by the server. For example, if the web client list (in order) is 1 2 3 4 and the

server list is 4 3 2, cipher 2 will be chosen because it is the first cipher present in the

web client's list that is also present on the server list.

This concept is illustrated in Figure 4-1.