Stronghold Web Server 4.0’s mod_ssl module implements authentication and encryption using the Secure Socket Layer (SSL) and the Transport Layer Security (TLS). Both are protocols for transmitting encrypted data over TCP/IP networks. They serve two important purposes:
This chapter discusses authentication and encryption topics:
For more information on authentication and encryption, see Chapter 2 of the mod_ssl manual: open a browser to http://your.server/stronghold/ and click on mod_ssl manual on the side bar.
For a list of old directive names and the current mod_ssl versions, refer to: http://www.modssl.org/docs/2.8/ssl_compat.html
Encryption is the encoding of data in order to hide its content from everyone except its intended recipient. The mathematical algorithms used to encrypt data are called ciphers. SSL and TLS are protocols for exchanging encrypted data over TCP/IP networks, including the Internet. Stronghold Web Server supports both SSL and TLS.
There are two types of ciphers: symmetric and asymmetric.
Public key ciphers require two keys: a public key and a private key. The public key encrypts data, but it cannot decrypt the same data. Only the private key can decrypt data that is encrypted with the public key.
Under this scheme, a web server gives its public key to the client at the beginning of a secure session. The browser then uses the web servers public key to encrypt its next transmission. The server uses its private key to decrypt that transmission.
Symmetric ciphers use a single key for all operations. Under this scheme, the sender and the recipient share the same key and use it for both encryption and decryption.
In order for two parties to share the same key, one must communicate it to the other privately. To do so, they use an asymmetric algorithm to encrypt the symmetric key so that it can only be decrypted by its intended recipient.
Symmetric algorithms are faster than public key algorithms, but public key algorithms are required to maintain privacy during the exchange of the faster symmetric keys. To preserve both efficiency and privacy, secure Web transactions begin with a public key exchange, followed by the exchange of a session key that implements a faster, symmetric cipher. These are the steps in the exchange:
The client and server now both have the same session key.
An SSL session may last for one or more transactions, and a session key encrypts all data in the session. Because the session key is encrypted using public key cryptography, the security of the private key in any public key pair is crucial to the security of a site. This is why guarding private key files is critical, through careful checking of file permissions and good passwords.
Every key pair must be accompanied by a site certificate in order to work. If several virtual hosts are configured, each hostname used must have its own key pair and certificate. Stronghold’s genkey utility:
# genkey hostname.example.com
The genkey utility runs automatically during server installation to create keys and a CSR for the main server host. It must be run separately for each additional host on the server.
Although the client generates the session key, the server influences the process by sending its cipher preferences along with its certificate. The client generates a session key that follows the symmetric cipher most preferred by both the client and the server. The security of a cipher depends on:
Cryptographers continuously attack and scrutinize ciphers and occasionally succeed in finding new weaknesses in existing ciphers. By seeking and publicizing weaknesses in ciphers, cryptographers can alert the public to security risks, and can also find ways to improve ciphers or create stronger ones. Most importantly, we can use this extensive peer-review to judge the level of confidence we can place in such ciphers.
Modern ciphers generally require an attacker to do a brute-force search through all possible keys to break any encrypted traffic. For ciphers with sufficiently large key sizes (for example, 128-bit) this is virtually inconceivable with today’s technology. Any cipher weakness that allows an improvement in "attack time", even if the improvement remains highly impractical to attempt, generally renders that cipher as "broken" — all software updates should remove support for such ciphers.
Stronghold interoperates with the ciphers listed below. Strong ciphers use 168-bit and 128-bit keys, 56-bit ciphers are considered quite weak; and 40-bit ciphers offer little or no security and should not be used on the Internet unless unavoidable.
| Cipher-Type | Security | Description |
|---|---|---|
| DES-CBC3-MD5 | Strong | 3DES in CBC, MD5 hash, 168-bit key |
| DES-CBC3-SHA | Strong | 3DES in CBC, SHA hash, 168-bit key |
| EDH-RSA-DES-CBC3-SHA | Strong | Ephemeral Diffie-Helman with RSA authentication, 3DES in CBC, SHA hash, 168-bit key |
| EDH-DSS-DES-CBC3-SHA | Strong | Ephemeral Diffie-Helman with DSS authentication, 3DES in CBC, SHA hash, 168-bit key |
| RC4-MD5 | Moderate | RC4 cipher, MD5 hash, 128-bit key |
| RC4-SHA | Moderate | RC4 cipher, SHA hash, 128-bit key (SSLv3/TLSv1 only) |
| RC2-CBC-MD5 | Moderate | RC2-compatible cipher in CBC mode, MD5 hash, 128-bit key |
| DES-CBC-MD5 | Moderate | DES in CBC, MD5 hash, 56-bit key |
| DES-CBC-SHA | Moderate | DES in CBC, SHA hash, 56-bit key |
| EDH-RSA-DES-CBC-SHA | Moderate | Ephemeral Diffie-Helman with RSA authentication, DES in CBC, SHA hash, 56-bit key |
| EDH-DSS-DES-CBC-SHA | Moderate | Ephemeral Diffie-Helman with DSS authentication, DES in CBC, SHA hash, 56-bit key |
| EXP-DES-CBC-SHA | Weak | DES in CBC, SHA hash, 40-bit key (SSLv3/TLSv1 only) |
| EXP-RC4-MD5 | Weak | Weakened for export, RC4 cipher, MD5 hash, 40-bit key |
| EXP-RC2-CBC-MD5 | Weak | Weakened for export, RC2-compatible cipher in CBC mode, MD5 hash, 40-bit key |
| EXP-EDH-RSA-DES-CBC | Weak | Weakened for export, Ephemeral Diffie-Helman with RSA authentication, DES in CBC, 40-bit key |
| EXP-EDH-DSS-DES-CBC-SHA | Weak | Weakened for export, Ephemeral Diffie-Helman with DSS authentication, DES in CBC, 40-bit key |
| EDH-DSS-DES-CBC-SHA | Moderate | Ephemeral Diffie-Helman with DSS authentication, DES in CBC, SHA hash, 56-bit key |
To see a list of the available ciphers, run the following command:
# bin/openssl ciphers -v
Any object on the site can be configured to require certain ciphers and forbid others. Three configuration directives control the ciphers used in Web transactions:
The value for each of these directives is a colon-separated list of ciphers. Use the cipher abbreviations shown in the table above. SSLCipherSuite (SSLCipherList) can also take a number of cipher aliases as values. For example, the following configuration allows three different ciphers for access to the virtual host (and its /about directory), but only two for access to its /employees directory:
<VirtualHost www.somesite.org:443> SSLEngine on SSLCipherSuite DES-CBC3-MD5:DES-CBC3-SHA:RC4-MD5 <Directory /about> FancyIndexing on </Directory> <Directory /employees> SSLRequireCipher DES-CBC3-MD5 SSLRequireCipher DES-CBC3-SHA </Directory> </VirtualHost>
The same effect could be achieved by using SSLBanCipher RC4-MD5 instead of the two SSLRequireCipher directives.
Important! Use either SSLRequireCipher or SSLBanCipher. Never use both for the same object.
Stronghold Web Server supports client authentication with X509 certificates. Client certificates are similar to server certificates, and they are currently the most reliable means of identifying users and restricting access. The current versions of Netscape Navigator and Microsoft Internet Explorer both support client certificates.
Until recently, most browsers only supported basic authentication which relies on usernames and passwords to authenticate users. The main disadvantage of basic authentication is that usernames and passwords can be communicated through unencrypted networks, allowing eavesdroppers to obtain the authentication criteria and access restricted material.
Client certificates can also be password-protected, but only on the user’s local host. The browser prompts the user for a password to prevent others from using the client certificate on the same machine, but the password does not enter the network — all network communication is fully secured with publicity cryptography.
Users obtain client certificates from a trusted third party CA or a private CA. Client certificates issued by major CAs are designed to provide authentication that any secure server can accept. Stronghold recognizes client certificates signed by Verisign, Thawte, and GeoTrust (the purchaser of Equifax’s digital certificate business). To accept other CAs (including private CAs) as being trusted to sign client certificates, see Installing New Client CA Certificates.
Since client certificates provide a reliable means of authenticating users, they also provide a reliable means of restricting access to material available from the server. For example, a directory can be configured to require a client certificate from any client who requests a file within that directory, and to require that the certificate meet certain criteria. To control access this way, use the SSLVerifyClient, SSLRequire, and SSLSH2Group directives (the use of SSLSH2Group is optional).
SSLVerifyClient indicates whether a client certificate is required in order to access a host. It has four possible values:
| Value | Description |
|---|---|
| none | A client certificate is not required. |
| optional | A client certificate is optional. |
| require | A valid client certificate is required. |
| optional_no_ca | A client certificate may be presented but need not be verifiable. |
When SSLVerifyClient is set to require, Stronghold Web Server requires a client certificate with all requests. The server checks each certificate’s signature using the public keys from the CA certificates in the ServerRoot/conf/ssl/CA/client-rootcerts.pem file. If the signature is invalid or originates with a CA whose certificate is not in client-rootcerts.pem, the request fails.
Access control with client certificates is enabled when:
SSLRequire sets the criteria used to accept or reject client certificates. A client certificate must meet these criteria in order to receive the requested material. This directive’s value can be:
An SSLRequire expression can refer to any one of a number of possible client certificate fields. For example, it can allow only certificates that; belong to clients in Denmark, were issued by your private CA, contain public keys larger than 512 bits, have previously been logged by the server, or belong to "Frank Roberts".
SSLSH2Group is a related directive that creates client authentication groups whose members all meet the same criteria. Its expression syntax is identical to that for SSLRequire, except that the certificate criteria is preceded by a group name. The group name can be used as the value for SSLRequire, specifying that the certificate must meet the criteria for that group. If the same client certificate criteria is used for man objects, SSLSH2Group provides a convenient shortcut.
By default, Stronghold Web Server accepts client certificates signed by Verisign, Thawte, and GeoTrust (the purchaser of Equifax’s digital certificate business); however, it can be configured to accept certificates signed by other CAs, such as a private CA. To do so, it must have the CA’s client root certificate. This is the certificate that is used to sign client certificates, and Stronghold must be configured to trust it before client certificates signed by the CA will be accepted by Stronghold. If the certificate is part of a chain, all certificates in the chain must be installed.
There are two ways to install a CA certificate; either by appending the certificate to the SSLCACertificateFile file or by installing the certificate file in the SSLCACertificatePath directory.
# cd ServerRoot/conf/ssl/CA
# cat newcert.pem > client-rootcerts.pem
# cp newcert.pem ServerRoot/conf/ssl/CA/newcert.pem
# openssl x509 -hash -noout < newcert.pem
The x509 utility returns a hash similar to the following:
5a35be
#mv newcert.pem 5a35be.0
If a file with this hash name already exists, name this one 5a35be.1 instead. Alternatively, create a symbolic link with the hash name instead of renaming the file itself:
# ln -s newcert.pem 5a35be.0
When installing a certificate chain, repeat these steps for each certificate in the chain.
Once the new CA certificate or chain is installed, Stronghold Web Server can automatically verify signatures on all client certificates signed by that CA.