Apache HTTP Server Version 2.3
Apache HTTP Server Version 2.3
The solution to this problem is trivial and is left as an exercise for the reader.
-- Standard textbook cookie
How to solve particular security problems for an SSL-aware webserver is not always obvious because of the interactions between SSL, HTTP and Apache's way of processing requests. This chapter gives instructions on how to solve some typical situations. Treat it as a first step to find out the final solution, but always try to understand the stuff before you use it. Nothing is worse than using a security solution without knowing its restrictions and how it interacts with other systems.
Your SSL configuration will need to contain, at a minumum, the following directives.
Listen 443
<VirtualHost _default_:443>
ServerName www.example.com
SSLEngine on
SSLCertificateFile /path/to/www.example.com.cert
SSLCertificateKeyFile /path/to/www.example.com.key
</VirtualHost>
The following enables only the strongest ciphers:
SSLProtocol all -SSLv2
SSLCipherSuite HIGH:!ADH:!EXP:!MD5:!NULL
While with the following configuration you enable two ciphers which are resonably secure, and fast:
SSLProtocol all -SSLv2
SSLCipherSuite RC4-SHA:AES128-SHA:HIGH:!ADH:!EXP:!MD5:!NULL
SSLHonorCipherOrder on
This strongly reflects the default value of SSLCipherSuite and is the recommanded way to configure it.
Obviously, a server-wide SSLCipherSuite which restricts
ciphers to the strong variants, isn't the answer here. However,
mod_ssl can be reconfigured within Location
blocks, to give a per-directory solution, and can automatically force
a renegotiation of the SSL parameters to meet the new configuration.
This can be done as follows:
# be liberal in general
SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
<Location /strong/area>
# but https://hostname/strong/area/ and below
# requires strong ciphers
SSLCipherSuite HIGH:!ADH:!EXP:!MD5:!NULL
</Location>
When you know all of your users (eg, as is often the case on a corporate
Intranet), you can require plain certificate authentication. All you
need to do is to create client certificates signed by your own CA
certificate (ca.crt) and then verify the clients against this
certificate.
# require a client certificate which has to be directly
# signed by our CA certificate in ca.crt
SSLVerifyClient require
SSLVerifyDepth 1
SSLCACertificateFile conf/ssl.crt/ca.crt
To force clients to authenticate using certificates for a particular URL,
you can use the per-directory reconfiguration features of
mod_ssl:
SSLVerifyClient none
SSLCACertificateFile conf/ssl.crt/ca.crt
<Location /secure/area>
SSLVerifyClient require
SSLVerifyDepth 1
</Location>
The key to doing this is checking that part of the client certificate
matches what you expect. Usually this means checking all or part of the
Distinguished Name (DN), to see if it contains some known string.
There are two ways to do this, using either mod_auth_basic or
SSLRequire.
The mod_auth_basic method is generally required when
the certificates are completely arbitrary, or when their DNs have
no common fields (usually the organisation, etc.). In this case,
you should establish a password database containing all
clients allowed, as follows:
SSLVerifyClient none <Directory /usr/local/apache2/htdocs/secure/area> SSLVerifyClient require SSLVerifyDepth 5 SSLCACertificateFile conf/ssl.crt/ca.crt SSLCACertificatePath conf/ssl.crt SSLOptions +FakeBasicAuth SSLRequireSSL AuthName "Snake Oil Authentication" AuthType Basic AuthBasicProvider file AuthUserFile /usr/local/apache2/conf/httpd.passwd Require valid-user </Directory>
The password used in this example is the DES encrypted string "password".
See the SSLOptions docs for more
information.
/C=DE/L=Munich/O=Snake Oil, Ltd./OU=Staff/CN=Foo:xxj31ZMTZzkVA /C=US/L=S.F./O=Snake Oil, Ltd./OU=CA/CN=Bar:xxj31ZMTZzkVA /C=US/L=L.A./O=Snake Oil, Ltd./OU=Dev/CN=Quux:xxj31ZMTZzkVA
When your clients are all part of a common hierarchy, which is encoded
into the DN, you can match them more easily using SSLRequire, as follows:
SSLVerifyClient none
<Directory /usr/local/apache2/htdocs/secure/area>
SSLVerifyClient require
SSLVerifyDepth 5
SSLCACertificateFile conf/ssl.crt/ca.crt
SSLCACertificatePath conf/ssl.crt
SSLOptions +FakeBasicAuth
SSLRequireSSL
SSLRequire %{SSL_CLIENT_S_DN_O} eq "Snake Oil, Ltd." \
and %{SSL_CLIENT_S_DN_OU} in {"Staff", "CA", "Dev"}
</Directory>These examples presume that clients on the Intranet have IPs in the range
192.168.1.0/24, and that the part of the Intranet website you want to allow
internet access to is /usr/local/apache2/htdocs/subarea.
This configuration should remain outside of your HTTPS virtual host, so
that it applies to both HTTPS and HTTP.
SSLCACertificateFile conf/ssl.crt/company-ca.crt
<Directory /usr/local/apache2/htdocs>
# Outside the subarea only Intranet access is granted
Order deny,allow
Deny from all
Allow from 192.168.1.0/24
</Directory>
<Directory /usr/local/apache2/htdocs/subarea>
# Inside the subarea any Intranet access is allowed
# but from the Internet only HTTPS + Strong-Cipher + Password
# or the alternative HTTPS + Strong-Cipher + Client-Certificate
# If HTTPS is used, make sure a strong cipher is used.
# Additionally allow client certs as alternative to basic auth.
SSLVerifyClient optional
SSLVerifyDepth 1
SSLOptions +FakeBasicAuth +StrictRequire
SSLRequire %{SSL_CIPHER_USEKEYSIZE} >= 128
# Force clients from the Internet to use HTTPS
RewriteEngine on
RewriteCond %{REMOTE_ADDR} !^192\.168\.1\.[0-9]+$
RewriteCond %{HTTPS} !=on
RewriteRule .* - [F]
# Allow Network Access and/or Basic Auth
Satisfy any
# Network Access Control
Order deny,allow
Deny from all
Allow 192.168.1.0/24
# HTTP Basic Authentication
AuthType basic
AuthName "Protected Intranet Area"
AuthBasicProvider file
AuthUserFile conf/protected.passwd
Require valid-user
</Directory>