|
In the first article of this three part series, the reader was shown how to install, configure, and troubleshoot Apache 2.0 with SSL/TLS support. Part two now discusses the recommended settings for the mod_ssl module that lets us achieve maximum security and optimal performance. The reader will also see how to create a local Certification Authority and a SSL certificate based on the free and open-source OpenSSL library.
Recommended settings for mod_ssl
In Apache 2.0.52, there are more than 30 directives that can be used to configure mod_ssl. The detailed description of all of them can be found in Apache's mod_ssl documentation. This section focuses only on the recommended settings which can improve the security or performance of SSL/TLS connections.
The list of these mod_ssl settings is shown below in Table 1.
|
Directive(s) |
Recommended setting or comment |
|
SSLEngine |
Must be enabled, otherwise the main server (or virtual host) will not be using SSL/TLS |
|
SSLRequireSSL |
Must be enabled, otherwise users may be able to access the web content via regular HTTP requests, without using SSL/TLS, at all. |
|
SSLProtocol
SSLProxyProtocol |
Should be set to use only TLS v1.0 and SSL v3.0. Most of current web browsers support both of them, so we can safely disable SSL v2.0. |
|
SSLCipherSuite
SSLProxyCipherSuite |
To provide strong cryptography, this parameter should be set to use HIGH (>168 bits) and MEDIUM (128 bits) cipher suites. LOW (<56 bits) and NULL (no encryption) cipher suites should be disabled, at all. It is also recommended to disable all cipher suites that support anonymous authentication (aNULL). Optionally, if we want to support web browsers that cannot deal with strong encryption we will need to enable EXPORT (56-bit and 40-bits) cipher suite. The last thing we should set is the preference on SHA1 over MD5. This is because SHA1 is considered to be more secure than MD5 after discoveries of MD5 . To summary, the recommended settings could be as follows:
HIGH:MEDIUM:!aNULL:+SHA1:+MD5:+HIGH:+MEDIUM
Note that it is possible to see what ciphers suites the proposed settings can support, as follows:
openssl ciphers -v 'HIGH:MEDIUM:\!aNULL:+SHA1:+MD5:+HIGH:+MEDIUM' |
|
SSLOptions |
The "+StrictRequire" options should be set, otherwise the "Satisfy Any" directive may force mod_ssl to allow access to the web content, even if SSL/TLS is not used. |
|
SSLRandomSeed |
For startup of Apache should be set to use pseudo random device (/dev/urandom) and/or EGD (Entrophy Gathering Daemon). Before establishing every new SSL connection should be configured to use built-in source, /dev/urandom or EGD. It is not recommended to use /dev/random in both cases, because /dev/random can provide only as much entropy, as it has at certain moment. |
|
SSLSessionCache |
To avoid repeating SSL handshakes for parallel HTTP requests (e.g. when web browser downloads several images at one time), SSL caching should be enabled. It should be set to use shared memory (SHM), or DBM. When setting to "none", performance of the web server may decrease significantly. |
|
SSLSessionCacheTimeout |
This value specifies the number of seconds, after which the entry in SSLSessionCache expires. It should be set to at least 300-600 seconds. However, the actual time should depend on the average time the users spent on visiting the web server. E.g., if the average time is around 15 minutes, then the value should be set to at least 900 (15 minutes * 60 seconds) |
|
SSLVerifyClient
SSLProxyVerify |
When not using client or proxy authentication, these options should be set to "none". They should never be set to "optional_no_ca", because it is against the idea of PKI authentication, where client, to be authenticated, must present valid certificate. "optional" may occasionally be used (depends on needs), however it may not work with all web browsers. |
|
SSLVerifyDepth
SSLProxyVerifyDepth |
Should contain the maximum number of intermediate CA's. E.g. to accept only self-signed certificates it should be set to zero, for client certificates that are signed by root CA - it should be 1. And so on. |
|
SSLProxyEngine |
Should be disabled, if SSL/TLS proxy mechanism is not used. |
Table 1. Recommended mod_ssl settings.
Our sample settings according to the above recommendations can be shown in httpd.conf as follows:
|
SSLEngine on
SSLOptions +StrictRequire
SSLRequireSSL
SSLProtocol -all +TLSv1 +SSLv3
# Support only for strong cryptography
SSLCipherSuite HIGH:MEDIUM:!aNULL:+SHA1:+MD5:+HIGH:+MEDIUM
# Support for strong and export cryptography
# SSLCipherSuite HIGH:MEDIUM:EXP:!aNULL:+SHA1:+MD5:+HIGH:+MEDIUM:+EXP
SSLRandomSeed startup file:/dev/urandom 1024
SSLRandomSeed connect file:/dev/urandom 1024
SSLSessionCache shm:/usr/local/apache2/logs/ssl_cache_shm
SSLSessionCacheTimeout 600
SSLVerify none
SSLProxyEngine off |
In addition to above mod_ssl directives, there are also two important directives from other Apache modules (mod_log_config and mod_set_envif) that need to be setup, as shown below in Table 2.
|
Directive(s) |
Recommended setting / comment |
|
CustomLog |
To log information about SSL parameters (recommended minimum: the protocol version and chosen cipher suites) we should use the following value:
|
CustomLog logs/ssl_request_log \
"%t %h %{HTTPS}x %{SSL_PROTOCOL}x %{SSL_CIPHER}x
%{SSL_CIPHER_USEKEYSIZE}x %{SSL_CLIENT_VERIFY}x
\"%r\" %b"
| |
|
Setenvif |
To provide compatibility with older versions of MS Internet Explorer, which has got known bugs in SSL implementation (e.g. problems with keep-alive functionality, HTTP/1.1 over SSL, and SSL close notify alerts on socket connection close), the following option should be set:
|
SetEnvIf User-Agent ".*MSIE.*" \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0 |
The above option will cause that web server will neither use HTTP/1.1 nor keep-alive connections, and will not send SSL close notify when the web browser is MS Internet Explorer. |
Table 2. Recommended mod_log and mod_set_envif settings.
The sample configuration file (httpd.conf) presented in the previous article already includes the above settings, for the reader's convenience.
Web server authentication
Thus far we were able to configure and test SSL/TLS, but our web browser was not able to check the web server's identity. In the first article we were using a web server certificate that had been created only for testing purposes, and did not contain the information required for real authentication purposes and commerce transactions.
In order for the web browser to successfully authenticate the web server, we need to create a valid web server certificate, which should contain:
- the public key of the web server
- validity dates (start and expiration)
- supported cipher algorithms
- the distinguish name (DN), which must contain fully qualified domain name of the web server known as the Common Name (CN). Optionally it may also contain some other attributes, like Country (C), State (S), Location (L), the Organization's name (O), the Organization Unit's name (OU), and more.
- the serial number of the certificate
- X.509v3 attributes that will tell web browsers about the type and usage of the certificate
- URI of the CRL distribution point (if exist)
- URI of the X.509v3 Certificate Policy (if exist)
- name and signature of trusted Certification Authority (CA)
It is important to note that the Common Name (CN) attribute must be a fully qualified domain name (FQDN) on the web server. Otherwise, the web browsers will not be able to verify if the certificate belongs to the web server that is presenting it.
A sample web server certificate (as a text representation) has been presented below.
|
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 1 (0x1)
Signature Algorithm: sha1WithRSAEncryption
Issuer: O=Seccure, OU=Seccure Root CA
Validity
Not Before: Nov 28 01:00:20 2004 GMT
Not After : Nov 28 01:00:20 2005 GMT
Subject: O=Seccure, OU=Seccure Labs, CN=www.seccure.lab
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
00:c1:19:c7:38:f4:89:91:27:a2:1b:1d:b6:8d:91:
48:63:0e:3d:0d:2e:f8:65:45:56:db:98:4d:11:21:
01:ac:81:8e:3f:64:4a:8a:3f:21:15:ca:49:6e:64:
5c:5d:a2:ab:5a:48:cb:2a:9f:0c:02:b9:ff:52:f6:
d9:39:6d:a3:4a:94:41:f9:e9:ab:f0:42:fb:68:9a:
4b:53:41:e7:4f:b0:2b:02:d7:92:a2:2b:02:a2:f9:
f1:2d:68:fa:50:01:2f:49:c1:28:2f:a8:c6:6d:6d:
ab:1d:b9:bd:c9:80:63:f1:d6:22:19:de:2d:4a:43:
50:76:79:7e:a5:5a:75:af:19
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Netscape Cert Type:
SSL Server
X509v3 Key Usage:
Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Server Authentication, Netscape Server Gated Crypto,
Microsoft Server Gated Crypto
Netscape Comment:
OpenSSL Certificate for SSL Web Server
Signature Algorithm: sha1WithRSAEncryption
45:30:9d:04:0e:b7:86:9e:61:a1:b0:68:2b:44:93:1c:57:2a:
99:42:bb:16:b1:ab:f5:c0:d2:33:12:c8:d3:1d:2b:bb:6b:9a:
4c:c7:53:bc:e4:88:ef:1e:c3:37:ed:53:2c:15:cf:b8:90:df:
df:4b:34:b8:db:cc:23:77:46:06:72:9d:43:60:a8:a2:ed:0a:
bb:1a:a4:e8:4e:ba:66:93:63:74:87:fd:43:48:b6:93:a2:e3:
3d:da:1b:64:46:35:88:b4:4b:22:e6:3c:84:70:5d:88:dd:64:
c2:51:c2:d6:59:80:87:bc:bd:7f:e3:c1:45:7e:c0:5f:9c:ca:
e1:a1 |
The examples presented in the subsequent sections of this article are based on the following values, as shown in Table 3. In order to create valid certificates, readers will need to replace these values with the names of their own company or organization.
Attribute's description |
Attribute |
Sample value |
|
Country code (two letters) |
C |
C = PL |
| State or Province |
S |
S = mazowieckie |
|
Location |
L |
L = Warsaw |
|
Organization Name |
O |
O = Seccure |
|
Organization Unit |
OU |
OU = Seccure Labs |
|
Common Name |
CN |
CN = www.seccure.lab | Table 3. Sample values for a valid certificate.
The passphrase dilemma
Before creating certificates, it is important to understand the implications of a passphrase for the certificate. Should the web server's private key be encrypted or not? There are many opinions, but it is recommended that one does not protect the web server's private key using passphrase. It is not only inconvenient, but also gives a false sense of security. Why? Consider the points below.
- One is required to enter the passphrase after every restart of the web server, which can be quite annoying if the system needs to be restarted often (such as due to a kernel update, an electricity failure, configuration change, and so on).
- If an intruder manages to get the private key on the web server, it means that the web server is compromised and the intruder had had access to the web server's operating system at root level. If this is the case, the intruder could obtain the passphrase by installing keylogger, and either crash or restart the system to force administrator to enter the passphrase. Alternatively, an intruder could dump Apache's memory and find the web server's private key stored as clear text there. While it is little bit difficult, for those skilled in the art of hacking Unix it should not pose a big problem (hint: look at the pcat utility from The Coroner's Toolkit).
Therefore, the only advantage of encrypting web server's private key is that the passphrase will help protect web server's private key against script kiddies, but not against professionals who are able to compromise the server.
Creating the web server certificate
At this point we can create our web server certificate. In general, there are three types of certificates that we can use:
- A self-signed certificate.
- A certificate signed by trusted CA (most recommended).
- A certificate signed by a local CA.
The sections below describe in detail the methods of creating the above certificates. The final result of any method used will be just two files:
- server.key - the private key of the web server
- server.crt - the PEM encoded certificate that includes our web server's public key
Method 1: Self-signed certificate (for testing purposes only)
This method is recommended only for continuing our testing, or for use in small, closed environments (such as at home or in small Intranets). In order for the web browsers to be able to authenticate the web server, self-signed certificates must be installed in every web browser that needs access the web server. This can be quite inconvenient.
The web server's private/public key pair and the self-signed PEM-encoded certificate now can be created as follows:
openssl req \
-new \
-x509 \
-days 365 \
-sha1 \
-newkey rsa:1024 \
-nodes \
-keyout server.key \
-out server.crt \
-subj '/O=Seccure/OU=Seccure Labs/CN=www.seccure.lab' |
The above commands will create a new (-new) certificate (-x509) that will be valid for one year (-days 365) and will be signed using the SHA1 algorithm (-sha1). The RSA private key will be 1024 bits long (-newkey rsa:1024), and will not be protected by a passphrase (-nodes). The certificate and the private/public key pair will be created in the "server.crt" and "server.key" files (-out server.crt -keyout server.key). The "-subj" parameter says that the company's name is "Seccure" (O=Seccure), the department's name is "Seccure Labs", and the web server's fully qualified domain name is "www.seccure.lab".
After creating the above certificate, we need to distribute and install it in every web browser that may connect to the web server. Otherwise, web browsers requiring a connection will not be able to verify the web server's identity. For Windows environments, this is shown below in Figure 1.
 Figure 1. Installing a self-signed certificate onto a client machine.Method 2: Certificate signed by a trusted CA (recommended method)
Creating a certificate request and signing it by a trusted CA (such as Verisign,Thawte, RSA, or others) is the most recommended way to proceed if the SSL web server is to be exposed to the Internet. Using this approach, there is no need to install certificates in each web browser, since most of them already have a number of trusted CA certificates pre-installed out-of-the-box.
Please note that each Certificate Authority has different restrictions for the Distinguish Name's attributes, to accommodate certain key lengths or international characters, and therefore prior to creating certificate requests readers need to make sure that certificate request is compliant with their particular CA's requirements. It is also recommended that one choose a CA whose signing certificate is already installed in most of web browsers (including Thawte, Verisign, and a number of others). Otherwise, the user's web browser may have problems authenticating with the web server.
The process of obtaining a signed certificate from trusted CA consists of the following steps:
- In the first step, we should create our web server's private/public key pair (server.key), and certificate request (request.pem), as follows:
openssl req \
-new \
-sha1 \
-newkey rsa:1024 \
-nodes \
-keyout server.key \
-out request.pem \
-subj '/O=Seccure/OU=Seccure Labs/CN=www.seccure.lab' |
- Now we must send the certificate request (request.pem) to the CA, and then wait until it is signed and sent back to us in the form of certificate.
- After receiving certificate back from our trusted CA, we must make sure that it is encoded in the PEM format, and not in TXT or DER format. If the received certificate is not PEM-encoded, then we will need to convert it from whatever format we have received.
The easiest way to check the format of the certificate is to view the certificate with a text editor. Depending on how the certificate look, it can be in one of the following formats (the typical filename extensions has been presented in the brackets):
- PEM, Base64 encoded X.509 format (*.crt, *.pem, *.cer)
-----BEGIN CERTIFICATE-----
MIICdzCCAeCgAwIBAgIBATANBgkqhkiG9w0BAQUFADAsMRAwDgYDVQQKEwdTZWNj
dXJlMRgwFgYDVQQLEw9TZWNjdXJlIFJvb3QgQ0EwHhcNMDQxMTI4MDEwMDIwWhcN
...
ou0Kuxqk6E66ZpNjdIf9Q0i2k6LjPdobZEY1iLRLIuY8hHBdiN1kwlHC1lmAh7y9
f+PBRX7AX5zK4aE=
-----END CERTIFICATE----- |
- TXT + PEM format (*.crt, *.cer, *.pem, *.txt)
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 1 (0x1)
Signature Algorithm: sha1WithRSAEncryption
Issuer: O=Seccure, OU=Seccure Root CA
...
RSA Public Key: (1024 bit)
Modulus (1024 bit):
00:c1:19:c7:38:f4:89:91:27:a2:1b:1d:b6:8d:91:
...
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
...
-----BEGIN CERTIFICATE-----
MIICdzCCAeCgAwIBAgIBATANBgkqhkiG9w0BAQUFADAsMRAwDgYDVQQKEwdTZWNj
dXJlMRgwFgYDVQQLEw9TZWNjdXJlIFJvb3QgQ0EwHhcNMDQxMTI4MDEwMDIwWhcN
...
ou0Kuxqk6E66ZpNjdIf9Q0i2k6LjPdobZEY1iLRLIuY8hHBdiN1kwlHC1lmAh7y9
f+PBRX7AX5zK4aE=
-----END CERTIFICATE----- |
If your certificate was received in TXT + PEM format, here is the command to convert it to PEM:
openssl x509 -in signed_cert.pem -out server.crt |
- DER, binary encoded X.509 (*.der, *.crt, *.cer)
[ non-text, binary representation ]
|
If your certificate was received in DER format, here is the command to convert it to PEM:
openssl x509 -in signed_cert.der -inform DER -out server.crt |
- Verify and test the certificate
Before installing the certificate we should check if the received certificate is indeed valid and can be used for web server authentication purposes:
openssl verify -CAfile /path/to/trusted_ca.crt -purpose sslserver server.crt |
Also, it is good to make sure that the certificate corresponds to our previously created web server's private key (the results of both commands below should be identical):
openssl x509 -noout -modulus -in server.crt | openssl sha1
openssl rsa -noout -modulus -in server.key | openssl sha1 |
Method 3: Certificate signed by a local CA
This third method of signing a certificate can be used in Intranets as well as all organizations that use, or plan to use, their own Certification Authority. In this case, a local CA certificate must be installed in all web browsers that connect to the secure web server.
To be able to use this method, we need to create our local CA's private/public key, as well as the CA's certificate and repository for the new keys.
Note: The local CA should be created on a separate server that is not connected to the network at all. The operating system should allow access only to authorized people, and the machine itself should be physically secured. The CA's private key is the most precious element of the entire PKI system - if this key is compromised, then all other certificates signed by this CA are considered compromised as well!
We will use the OpenSSL library to setup the environment step by step, as listed below. Of course, if we already have a local CA, we can skip this section and proceed with creating the certificate request for the web server.
- Prepare the directory structure for the new CA (the $SSLDIR environment variable should be added to applicable startup scripts, such as /etc/profile or /etc/rc.local):
export SSLDIR=$HOME/ca
mkdir $SSLDIR
mkdir $SSLDIR/certs
mkdir $SSLDIR/crl
mkdir $SSLDIR/newcerts
mkdir $SSLDIR/private
mkdir $SSLDIR/requests
touch $SSLDIR/index.txt
echo "01" > $SSLDIR/serial
chmod 700 $SSLDIR |
- Create the main OpenSSL configuration file - $SSLDIR/openssl.cnf, with the following content (optimized for the use with SSL web servers):
# =================================================
# OpenSSL configuration file
# =================================================
RANDFILE = $ENV::SSLDIR/.rnd
[ ca ]
default_ca = CA_default
[ CA_default ]
dir = $ENV::SSLDIR
certs = $dir/certs
new_certs_dir = $dir/newcerts
crl_dir = $dir/crl
database = $dir/index.txt
private_key = $dir/private/ca.key
certificate = $dir/ca.crt
serial = $dir/serial
crl = $dir/crl.pem
RANDFILE = $dir/private/.rand
default_days = 365
default_crl_days = 30
default_md = sha1
preserve = no
policy = policy_anything
name_opt = ca_default
cert_opt = ca_default
[ policy_anything ]
countryName = optional
stateOrProvinceName = optional
localityName = optional
organizationName = optional
organizationalUnitName = optional
commonName = supplied
emailAddress = optional
[ req ]
default_bits = 1024
default_md = sha1
default_keyfile = privkey.pem
distinguished_name = req_distinguished_name
x509_extensions = v3_ca
string_mask = nombstr
[ req_distinguished_name ]
countryName = Country Name (2 letter code)
countryName_min = 2
countryName_max = 2
stateOrProvinceName = State or Province Name (full name)
localityName = Locality Name (eg, city)
0.organizationName = Organization Name (eg, company)
organizationalUnitName = Organizational Unit Name (eg, section)
commonName = Common Name (eg, YOUR name)
commonName_max = 64
emailAddress = Email Address
emailAddress_max = 64
[ usr_cert ]
basicConstraints = CA:FALSE
# nsCaRevocationUrl =
[ ssl_server ]
basicConstraints = CA:FALSE
nsCertType = server
keyUsage = digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth, nsSGC, msSGC
nsComment = "OpenSSL Certificate for SSL Web Server"
[ ssl_client ]
basicConstraints = CA:FALSE
nsCertType = client
keyUsage = digitalSignature, keyEncipherment
extendedKeyUsage = clientAuth
nsComment = "OpenSSL Certificate for SSL Client"
[ v3_req ]
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
[ v3_ca ]
basicConstraints = critical, CA:true, pathlen:0
nsCertType = sslCA
keyUsage = cRLSign, keyCertSign
extendedKeyUsage = serverAuth, clientAuth
nsComment = "OpenSSL CA Certificate"
[ crl_ext ]
basicConstraints = CA:FALSE
keyUsage = digitalSignature, keyEncipherment
nsComment = "OpenSSL generated CRL" |
- Now create the CA's private/public key pair, and the self-signed CA's certificate:
openssl req \
-config $SSLDIR/openssl.cnf \
-new \
-x509 \
-days 3652 \
-sha1 \
-newkey rsa:1024 \
-keyout $SSLDIR/private/ca.key \
-out $SSLDIR/ca.crt \
-subj '/O=Seccure/OU=Seccure Root CA' |
It should be emphasized that the CA's private key (ca.key) should be protected by a hard to guess passphrase, and it should be valid for a much longer period of time than regular certificates (typically, 10-30 years, or more).
The CA's certificate "ca.crt" should be published on Intranet web pages and installed in every web browser that may possibly need to use it. A sample root CA certificate installed in Internet Explorer is shown below in Figure 2.
 Figure 2. Sample root CA certificate installed in Internet Explorer.From this point we can now use our local CA for signing/revoking certificates. In order to create the web server certificate, we should follow the below steps:
- Create the web server's private/public key pair (server.key), and the certificate request (request.pem). This instruction needs to be executed on the web server.
openssl req \
-new \
-sha1 \
-newkey rsa:1024 \
-nodes \
-keyout server.key \
-out request.pem \
-subj '/O=Seccure/OU=Seccure Labs/CN=www.seccure.lab' |
- Copy the above certificate request (request.pem) into the $SSLDIR/requests directory on the CA host (using removable media, such as a USB-Drive).
- Sign the certificate request as follows (to be executed on the CA host only):
openssl ca \
-config $SSLDIR/openssl.cnf \
-policy policy_anything \
-extensions ssl_server \
-out $SSLDIR/requests/signed.pem \
-infiles $SSLDIR/requests/request.pem |
The result of the above command is a signed certificate (signed.pem) that is placed in the $SSLDIR/newcerts directory, and in the file $SSLDIR/signed.pem. It consists of both a TXT and PEM representation of the certificate. Because Apache expects a pure PEM format, we need to convert it, as follows:
openssl x509 \
-in $SSLDIR/requests/signed.pem \
-out $SSLDIR/requests/server.crt |
- Copy the signed, PEM-encoded certificate (server.crt) back to the web server machine.
At this point web server's certificate is ready to use.
For local Certificate Authorities, if the web server's certificate is compromised it is CA responsibility to revoke the certificate, and to inform users and applications that this certificate is no longer valid.
To revoke a certificate, we need to find the serial number of the certificate we want to revoke in the $SSLDIR/index.txt file. Then, we can revoke the certificate as follows:
openssl ca \
-config $SSLDIR/openssl.cnf \
-revoke $SSLDIR/newcerts/.pem |
To create a CRL (Certificate Revocation List) file, we can use the following commands:
openssl ca -config $SSLDIR/openssl.cnf -gencrl -crlexts crl_ext -md sha1 -out $SSLDIR/crl.pem |
The above file should be published on the CA's website, and/or distributed to users. When distributing CRLs it is also recommended that one use the Online Certificate Status Protocol (OCSP). More information about OCSP can be found in .
Note that some browsers (including Firefox) accept only DER-encoded CRLs, so prior to installing crl.pem in such browsers, the file must be converted as follows:
openssl crl \
-in $SSLDIR/crl.pem \
-out $SSLDIR/revoke_certs.crl \
-outform DER |
Also note that in order for the web browser to check if the web server's certificate is revoked, the option "Check for server certificate revocation" should be checked in MS Internet Explorer's Advanced Settings. This is shown below in Figures 3 and 4.
 Figure 3. Configuring Internet Explorer to check for certificate revocation.  Figure 4. Internet Explorer's response to a revoked certificate.Installing the certificate
At this point we can proceed with installing the web server's private key (server.key) and certificate (server.crt) into the Apache environment:
install -m 600 -o root -g sys server.key /usr/local/apache2/conf/ssl.key/
install -m 644 -o root -g sys server.crt /usr/local/apache2/conf/ssl.crt/ |
We should also make sure that the directives in Apache's configuration file are pointing to the above files (in httpd.conf):
SSLCertificateFile /usr/local/apache2/conf/ssl.crt/server.crt
SSLCertificateKeyFile /usr/local/apache2/conf/ssl.key/server.key |
The final step is to restart Apache for the changes to take an effect:
/usr/local/apache2/bin/apachectl stop
/usr/local/apache2/bin/apachectl startssl |
At this point we can check to see if the SSL website is accessible from the web browsers, and if the web browsers can successfully authenticate with the web server. This time, there should be no warning messages displayed, as shown below in Figure 5.
 Figure 5. Secure connection with a valid certificate.Concluding part two
It has been shown how to configure mod_ssl, and how to create and use a web server's X.509v3 certificates. Next, in the third and final part of this article series, we will discuss client authentication via certificates, as well as common mistakes and known attacks that can threaten the security of SSL communication.
|
Part 3Artur Maj 2005-03-01
Introducing part threeThis article concludes our three part series dedicated to configuring Apache 2.0 with SSL/TLS support -- for maximum security and optimal performance of SSL based e-commerce transactions.
Part one introduced key aspects of SSL/TLS and then showed how to compile, install and configure Apache 2.0. The second part discussed the configuration of mod_ssl and authentication issues, and then showed how to create web server's SSL certificate.
Now, in the third and final article, we will take a look at client authentication using client certificates, show how to chroot a secure Apache, discuss common attack vectors, and then describe some typical configuration mistakes made by administrators that will decrease the security level of SSL communications.
Client authenticationOne of the most popular methods for authenticating users in web applications is a password, passphrase or PIN, in other words, "something you know." The greatest advantage of such a method is its simplicity. For an administrator, it is enough to add few directives to httpd.conf and create a passwd file to implement such a schema.
Unfortunately, because of their simplicity passwords are vulnerable to a number of attacks. They can be guessed, sniffed over the wire, brute-forced, stolen (such as when a user writes them down on sticky notes) or coaxed out (through social engineering or some kind of "phishing" method). This is why standard password authentication is considered to be weaker than using one-time passwords, hardware tokens or others forms of authentication.
Few people realize that when using a SSL web server there is an stronger method of authenticating users: client SSL certificates, or "personal" certificates for each user. In this method, we can authenticate web users based on "something you have," using a certificate and a private key corresponding to the client certificate, as well as "something you know," which would be a passphrase to the private key. Thus, using certificates is more secure than using standard password solutions, mainly because besides an intruder would need to get both pieces of authentication -- the private key that corresponds to the user's certificate, as well as the passphrase -- to gain access. Moreover, unlike a standard password, the certificate's passphrase is not actually sent over the network at all, it is used only locally to decrypt the private key.
As will be shown, the implementation of this method of authentication is not complicated and it can be performed in few steps, which administrators will find to be almost as easy as the more popular Basic Authentication password method.
Configuring Apache to use client certificatesIn order to configure Apache to support client authentication via X.509v3 certificates, we need to perform four actions:
- Enable client authentication in the Apache's web server
To enable the use of client certificates, we need to add the following directives to httpd.conf:
|
SSLVerifyClient require
SSLVerifyDepth 1 |
Thanks to the SSLVerifyClient directive, the access to the web server will now be limited only to the web browsers that present a valid certificate, one which is signed by our local CA. Note that the process of creating local CA has been described in the previous article. The "SSLVerifyDepth" value specifies the maximum depth of the intermediate certificate issuers in the chain of certificates. In our case, we will set this value to "1," because all client certificates must be signed by our local CA -- we are not using intermediate CAs.
- Install the local CA's certificate into the Apache directory structure.
|
install -m 644 -o root -g sys ca.crt /usr/local/apache2/conf/ssl.crt/ |
- Set the SSLCACertificateFile directive (in httpd.conf) to point to the CA certificate we just installed.
|
SSLCACertificateFile /usr/local/apache2/conf/ssl.crt/ca.crt |
- Now restart Apache.
|
/usr/local/apache2/bin/apachectl stop
/usr/local/apache2/bin/apachectl startssl |
From now on, access to the web server via SSL will be granted only to the web browsers that present a valid client certificate, signed by our local CA. To test it, we can try to access the URL of the website. After establishing SSL connection, MS Internet Explorer will ask us to choose the client certificate we want to use, as shown below in Figure 1.
 Figure 1. Internet Explorer asking for a client certificate. Since we do not yet have any client certificate installed, access to the web server will simply be denied.
Creating a client certificateIn general, creating an individual client certificate is very similar to creating a web server certificate. The only difference is that we will use different X.509v3 extensions (the "ssl_client" section from openssl.cnf) and we will store both the private key and certificate in PKCS#12 format (also referred as PFX).
For the sake of simplicity, please follow the steps below using OpenSSL to produce the client certificate. Note that it is highly recommended that any actions that are to be performed by users (numbers 1, 2, 7, 8 in the steps below) should be as automated and simplified as possible to minimize user interaction and user error. To that end, additional technology such as Java Applets could be used. Alternatively, a dedicated host can also be used for the purpose of creating client certificates. In this latter case, users would need to visit the server in-person and enter their passphrase on the dedicated host to encrypt their own private key. Although this option might seem a bit inconvenient, it is the most secure method, as a user's identity can be verified and both the certificate and the private key can be passed to the user without sending it over the network.
The steps to create and install a client certificate are exactly as follows:
- Create a private/public key pair for the user, together with a certificate request. If a dedicated host is not being used to serve the certificate, this should be executed on the user's host:
|
openssl req \
-new \
-sha1 \
-newkey rsa:1024 \
-nodes \
-keyout client.key \
-out request.pem \
-subj '/O=Seccure/OU=Seccure Labs/CN=Frodo Baggins' |
- The user sends the certificate request (request.pem) to the local CA, to be signed.
- The local CA's task is to verify that the information from the client certificate request is indeed valid and correct.
- After verifying, the certificate request (request.pem) should be copied into the $SSLDIR/requests directory on the local CA host using removable media, such as a USB drive.
- The local CA should sign the certificate request as follows. This should be executed on the CA's host.
|
openssl ca \
-config $SSLDIR/openssl.cnf \
-policy policy_anything \
-extensions ssl_client \
-out $SSLDIR/requests/signed.pem \
-infiles $SSLDIR/requests/request.pem |
- The local CA should send the certificate (signed.pem) to the user.
- After receiving the signed certificate, users need to store their private key together with their certificate into PKCS#12 format.
|
openssl pkcs12 \
-export \
-clcerts \
-in signed.pem \
-inkey client.key \
-out client.p12 |
The newly created client.p12 file should be protected with a hard-to-guess passphrase. All other files (including the unencrypted private key, the signed certificate and the certificate request) should be securely erased from the user's disk space using a utility.
|
wipe client.key signed.pem request.pem |
- The client certificate, together with the private key, should be installed in the user's web browser. An example of this for Microsoft Internet Explorer is shown below in Figure 2.
 Figure 2. Installing a certificate in Internet Explorer. To protect the private key against accidental or unauthorized use, the option "Enable strong private key protection" should be checked. Also, to protect the certificate from being stolen, it should be not be possible to export the certificate -- the option "Mark this key as exportable" should be disabled. Both these browser configuration options are shown below in Figure 3.
 Figure 3. Protecting the client certificate in Internet Explorer. In addition, the security level of the browser should be changed to "High." We see this during the next step of the Import Wizard, as illustrated below in Figure 4. Thanks to this option, a user will be asked to enter his password every time the web browser wants to use that client certificate.
 Figure 4. Security level should be set to "High" in IE.
That's all there is to it. The certificate can now be found under the "Personal" tab in the certificate view (in MS Internet Explorer's menu -> tab "Content" -> "Certificates"). If we double click the certificate we should see some properties similar to Figure 5, below.
 Figure 5. Client certificate details in IE. Using the client certificateAt this point we should try to access the URL of the website again. If the above have been successfully completed, once it is requested we should be able to see and choose the installed certificate from the list, as shown in Figure 6.
 Figure 6. Choosing the client certificate when prompted. After choosing the certificate, the user must enter the required passphrase that decrypts the corresponding private key, as shown in Figure 7.
 Figure 7. Entering the passphrase for the certficate. Now we will have access to the secure website, illustrated in Figure 8.
 Figure 8. Secure access, using certificates, has been granted. Customizing access controlWith additional server-side directives, we can control which parts of the website particular users or groups of users are granted or denied access. For example, when and organization must deal securely with many different companies, we can restrict access to the website to just one particular company (O=Seccure), by adding the following directives to httpd.conf:
|
SSLRequire %{SSL_CLIENT_S_DN_O} eq "Seccure"
|
Another example shows how to allow access only to a certain department (OU="Seccure Labs") within the company (O="Seccure"):
|
SSLRequire %{SSL_CLIENT_S_DN_O} eq "Seccure" and \
%{SSL_CLIENT_S_DN_OU } eq "Seccure Labs" |
Or alternatively, we can provide access to just a few departments (OU="Seccure Labs" or OU="Development") within the same company (O="Seccure"):
|
SSLRequire %{SSL_CLIENT_S_DN_O} eq "Seccure" and \
%{SSL_CLIENT_S_DN_OU } in {"Seccure Labs", "Development"} |
Finally, we can even provide access to just one specific user (CN="Frodo Baggins") from a specific company (O="Seccure"):
|
SSLRequire %{SSL_CLIENT_S_DN_O} eq "Seccure" and \
%{SSL_CLIENT_S_DN_CN} in {"Frodo Baggins"} |
Note that we can also provide the above environment variables to CGI scripts (including PHP and others), by adding the "+StdEnvVars" parameter to the SSLOptions directive. This features allows us to use DN names inside web applications (PHP and others), to provide more detailed authorization and access control.
Revoking a client certificateIf a client certificate becomes compromised or lost, what do you do? In this case we need to revoke the certificate, as was already described in the previous article. Then, we must copy the CRL file into the Apache directory, as follows:
|
install -m 644 -o root -g sys crl.pem /usr/local/apache2/conf/ssl.crl/ |
We also need to make sure that the "SSLCARevocationFile" in httpd.conf points to the above file:
|
SSLCARevocationFile /usr/local/apache2/conf/ssl.crl/crl.pem |
Then, we need to restart Apache for the changes to take an effect. The revoked certificates will not be allowed access to the website, as shown below in Figure 9.
 Figure 9. Access attempted with a revoked certificate. Chrooting the serverTo improve our web server's security and make Apache less vulnerable to buffer overflow attacks, it is recommended that one run Apache in the chrooted environment. Chrooting the web server isolates the process to a new root directory so that it cannot see the rest of the server's files.
The process of chrooting Apache has been already described in "Securing Apache 2.0: Step-by-Step," so readers are encouraged to follow steps that were shown there. With the added support for SSL/TLS, we will need to install some additional libraries and create a few new subdirectories. In the case of FreeBSD 5.1, the list of these libraries and directories are as follows:
|
cp /usr/lib/libssl.so.3 /chroot/httpd/usr/lib/
cp /usr/lib/libcrypto.so.3 /chroot/httpd/usr/lib/
cp -R /usr/local/apache2/conf/ssl.key /chroot/httpd/usr/local/apache2/conf/
cp -R /usr/local/apache2/conf/ssl.crt /chroot/httpd/usr/local/apache2/conf/
cp -R /usr/local/apache2/conf/ssl.crl /chroot/httpd/usr/local/apache2/conf/ |
We also need to add urandom device as follows. Once again, the example below is taken from FreeBSD 5.1:
|
ls -al /dev/*random
crw-rw-rw- 1 root wheel 2, 3 Jan 4 12:10 /dev/random
lrwxr-xr-x 1 root wheel 7 Jan 4 12:10 /dev/urandom -> random
cd /chroot/httpd/dev
mknod ./random c 2 3
ln -s ./random ./urandom
chown root:sys ./random
chmod 666 ./random |
In the case of other operating systems, readers can create the list of required files by using commands like truss, strace, ktrace etc., as was described in details in the section "Chrooting the server," from the SecurityFocus article, "Securing Apache: Step-by-Step"
Once all these steps have been completed, we can run Apache in the chrooted environment, as follows:
|
chroot /chroot/httpd /usr/local/apache2/bin/httpd |
Known attacks on SSL/TLSAlthough SSL/TLS protocols offer a high level of security in theory, its actual implementations may be vulnerable to several types of attacks. Of the many attack vectors, two are worthy of special attention:
- Man in the middle (MITM) attacks
In this type of attack, an intruder intercepts the traffic that is being sent between a client and server, such as by forging DNS replies or by performing ARP redirection. Then, it impersonates the client to the server, and vice-versa. During this attack, the user's web browser does not connect directly to the destination server, but instead to the intruder host, which impersonate the web browser and essentially acts as a proxy.
There is good and bad news for an administrator who wishes to defend against such attacks. The good news is that the web browsers warn users when the web server's identity cannot be verified, which may indicate possible man-in-the-middle attack, by displaying a message window with a warning. The bad news is that in real life, users very often ignore such warnings. Hence, if the user's web browser accepts connections to SSL web sites that identities cannot be checked, we can only rely on users' education and trust that they will not press the "proceed" button, if such warning message has been displayed.
- Brute-force attack on the session key
This attacks can be performed when the intruder knows or can assume part of the clear text that was sent during SSL/TLS session, such as (such as "GET / HTTP/1.0"), and the intruder can eavesdrop this session (such by using , or other tools). Then, intruder can encrypt the assumed part of the text by using every possible key, trying to find its occurrence in the originally encrypted SSL/TLS traffic. Once such an occurrence has been found, the key that was used to encrypt this part of the message can be used to decrypt the rest of originally encrypted SSL/TLS traffic.
The good news is that maximum number of keys that must be checked is 2^128 when 128-bit symmetric cryptography has been used. Today this is believed to be strong enough to protect the session for literally dozens of years. However, since CPUs grow in strength every year, we cannot really predict for how long 128-bit symmetric keys will be considered to be secure, particularly for hackers with access to large supercomputers.
In case of export-class cipher suites (40-bit, and in some extended 56-bit ciphers) such brute force attacks can be successfully performed in a reasonable amoung of time -- sometimes even in few days, depending on the available number of CPUs. If export regulations in your country allow for the use of strong cryptography, one should definitely use it instead of export-class cipher suites.
In addition to the two types of attacks listed above, there are some other potential vulnerabilities, including algorithm rollback attacks, timing attacks, traffic analysis, Bleinchenbacher's attacks, and others. Those interested in understanding them can find more information in Bruce Schneier and David Wagner's document, "," (PDF document) as well as in many other documents that can be found on the .
Typical SSL/TLS implementation mistakes
- Certificates signed by a CA that is not known to the web browser
The biggest mistake that can be made when implementing SSL/TLS is with the signing of the web server's certificate by a CA that is not trusted by web browser. In other words, the CA's certificate is not installed in the web browser. This makes Man-In-The-Middle attacks very easy to perform, because users have no way of verifying the identity of the web server.
To avoid this problem, it is important to make sure that signer's certificate (usually, a trusted CA) is installed in user's web browser. If a local CA was used for signing the web server's certificate, then we must make sure that all web browsers on all clients requiring access have the local CA's certificate installed. The same rule applies to self-signed certificates.
- Expired certificates
The web browser's certificate should be renewed before the previous one expires. Otherwise it will result in the same problem as above, whereby web clients will not be able to authenticate with the web server -- which once again makes SSL/TLS connections vulnerable to man in the middle attacks. In this case, users may get used to seeing a warning message saying the certificate has expired, and then will probably not notice if it is a bogus certificate.
- Vulnerable versions of OpenSSL and Apache
It is very important to always run the latest versions of OpenSSL and Apache. Programmers writing larger pieces of code such as these without bugs is virtually impossible, so we should always use the latest stable versions of the above software. The latest versions should theoretically contain fewer security vulnerabilities (both discovered and not-yet discovered) than previous versions.
- Acceptance of SSL v2.0, anonymous authentication (aNULL), and cryptography (NULL) by the web server
As was previously discussed, the use of cipher suites that support anonymous authentication or require no encryption should be disabled. Otherwise, there is a risk that client can be tricked into negotiating parameters that can dramatically lower the security level of the connection. For this reason we should disable the use of the SSLv2.0 protocol and use TLSv1.0 or SSLv3.0 instead.
- Use of weak encryption
Early implementations of SSL were only able to use 40-bit keys for symmetric encryption, due to US government restrictions. Unfortunately, the data encrypted by 40-bits symmetric keys can now be decrypted in a relatively short period of time, and for this reason 40-bit and 56-bit keys should no longer be used. Most modern web browsers support 128-bit keys for symmetric encryption, and this is now the minimal recommended length of key for use with SSL/TLS.
- Improper use of a Network Intruder Detection System (NIDS)
It is important to stress that unless a NIDS is capable of decrypting the SSL traffic (such as through the use of the web server's private key) it is simply unable to detect attacks on the web application. To detect eventual break-ins, we must either use either a HIDS (Host-based Intruder Detection System), or put the NIDS in a segment where SSL/TLS traffic is being sent in clear text, such as between a SSL Reverse Proxy and the web server's farm. Otherwise we may not be able to detect any attacks, except denial of service, performed against the web server.
- Allowing access not only via SSL, but also via non-encrypted protocols (HTTP)
Setting up SSL/TLS and opening port 443/tcp to the web server, by itself, means nothing if users can still access website via non-encrypted HTTP on port 80/tcp. Thus, one must double-check that the protected content cannot be accessed via non-encrypted HTTP or other protocols (including FTP, Samba, NFS, and so on).
- Vulnerable client machines
When we focus on securing Apache web servers, we can easily forget about the security of the client machines. If they are compromised, the security of SSL/TLS is compromised as well. In that case, intruders could do as they like with client hosts, such as replace certificates in web browsers, install keyloggers, change /etc/hosts to redirect web requests to bogus web servers, or even steal client certificates if they they have been marked as "exportable."
Therefore, if the client machines are under our administrative domain, we need to take great care with their security. Enabling a personal firewall, antivirus/antispyware software, and turning on automatic Windows updates should be the absolute minimum. Most importantly, web browser versions should be always up-to-date.
It is also recommended that one apply the following options (related to SSL/TLS) to the web browser configuration:
- checking for a publisher's certificate revocation should be enabled
- checking for any server certificate revocation should be enabled
- encrypted server pages should not be stored in the cache
- the use of SSLv2.0 should be disabled, and only TLSv1.0 and SSLv3.0 should remain enabled
- the displaying of warnings about invalid web servers certificates should be enabled
- Using the same Session IDs / cookies for SSL and HTTP
It is possible to have an Apache configuration that accepts both HTTP and HTTPS requests on the same server, such as an information website accessible via HTTP, and a transaction part accessible via HTTPS. In this case, the we must be very careful in our web application not to use the same session IDs / cookies for both protocols. Otherwise, an intruder can sniff the HTTP traffic between web server and victim, and can try to use session IDs to get access to authorized part of web application via SSL.
ConclusionThis article closes the series of articles devoted to configuring Apache 2.0 with SSL/TLS support. It has been presented how to set up SSL/TLS protocol to achieve maximum security and optimal performance. It has been also shown how to create and revoke certificates, and how to use them in practice.
Although the series has covered most important aspects of Public Key Infrastructure for use with SSL web servers, including creating, installing using and revoking certificates, we did not exhaust the subject related to PKI. On the contrary, only the real basics of PKI have been presented. Readers interested in further reading on this topic are encouraged to take a look at the documents created by the , or the , where the latter is quite a robust and open-source Certification Authority.
|
Relevant Links
"The TLS Protocol, Version 1.0":
"SSL 3.0 Specification":
Apache Web Server Project:
OpenSSL project:
OpenCA project:
Mod_ssl website:
Securing Apache 2: Step-by-Step: http://www.securityfocus.com/infocus/1786
PKIX Working Group:
"Analysis of the SSL 3.0 protocol":
"Finite-State Analysis of SSL 3.0": http://verify.stanford.edu/uli/secur/usenix/usenix.html
"Wireless Application 2.0 Security":
Sample Apache configuration file: httpd.conf
Sample startup script: apache.sh
Sample Openssl configuration file: openssl.cnf
About the author
Artur Maj works as a Principal Software Engineer for Oracle Corporation, in the EMEA Mobile, Wireless & Voice Center of Expertise. He is experienced in designing computer systems, performing security audits as well as providing security training. He is also author of many articles and publications devoted to securing computer systems and software against intruders.
View more articles by Artur Maj on SecurityFocus.
| |
