defensive-coding-guide/Securing_TLS/en-US/mod_ssl.xml

155 lines
8.7 KiB
XML

<?xml version='1.0' encoding='utf-8' ?>
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
<!ENTITY % BOOK_ENTITIES SYSTEM "Securing_TLS.ent">
%BOOK_ENTITIES;
]>
<chapter id="chap-Fedora_Security_Team-Securing_TLS-mod_ssl">
<title>mod_ssl</title>
<para>
<application>Apache</application> web server utilizes <application>mod_ssl</application> to utilize OpenSSL for cryptography. Configuration is handled by the <filename>/etc/httpd/conf.d/ssl.conf</filename> file and can be modified to support a wide range of ciphers and protocols.
</para>
<section id="sect-Fedora_Security_Team-Securing_TLS-mod_ssl-configuration">
<title>Configuration</title>
<para>
<application>mod_ssl</application>'s configuration file, by default, has mostly sane settings. Below we'll talk about portions of the configuration that are important.
</para>
<para>
<screen>
#
# When we also provide SSL we have to listen to the
# the HTTPS port in addition.
#
Listen 443 https
</screen>
This specifies the port that httpd should listen to for SSL/TLS traffic. Port 443 is the standard port for https.
</para>
<para>
<screen>
# Pseudo Random Number Generator (PRNG):
# Configure one or more sources to seed the PRNG of the
# SSL library. The seed data should be of good random quality.
# WARNING! On some platforms /dev/random blocks if not enough entropy
# is available. This means you then cannot use the /dev/random device
# because it would lead to very long connection times (as long as
# it requires to make more entropy available). But usually those
# platforms additionally provide a /dev/urandom device which doesn't
# block. So, if available, use this one instead. Read the mod_ssl User
# Manual for more details.
SSLRandomSeed startup file:/dev/urandom 256
SSLRandomSeed connect builtin
#SSLRandomSeed startup file:/dev/random 512
#SSLRandomSeed connect file:/dev/random 512
#SSLRandomSeed connect file:/dev/urandom 512
#SSLRandomSeed connect exec:/usr/local/bin/rand 16
</screen>
The random number generator is very important for cryptology and this is where those settings get established. By default the pseudo-random number generator is configured here although if you have another source of random data you can specify it here.
</para>
<para>
For Linux systems, the quality of entropy provided by <literal>/dev/urandom</literal> is very high so we recommend its use for both <literal>startup</literal> and <literal>connect</literal>. The number of bytes read should be left at 256 for <literal>startup</literal> as it has minimal impact on performance, and set to 32 for the <literal>connect</literal> use (256 bits). This provides enough entropy for both internal operation and for ServerRandom value in TLS (which is limited to 256 bits).
</para>
<para>
In cases where the system on which <literal>mod_ssl</literal> is running is slow and doesn't have a hardware random number generator, we highly recommend to set the values to the ones quoted in the above example.
</para>
<para>
<screen>
# Use "SSLCryptoDevice" to enable any supported hardware
# accelerators. Use "openssl engine -v" to list supported
# engine names. NOTE: If you enable an accelerator and the
# server does not start, consult the error logs and ensure
# your accelerator is functioning properly.
#
SSLCryptoDevice builtin
#SSLCryptoDevice ubsec
</screen>
Many processors have cryptographic accelerators that help with complex ciphers such as AES. In fact, most hardware accelerators are specifically designed to increase the speed of AES-128 (see below where we talk about speed optimization). Unless you have a specific accelerator in your system this default setting should be okay.
<screen>
# SSL Protocol support:
# List the enable protocol levels with which clients will be able to
# connect. Disable SSLv2 access by default:
SSLProtocol all -SSLv2
</screen>
Here's where the really important settings begin (well, they are all important). SSLProtocol allows you to set which protocols to use (e.g. SSLv2, SSLv3, TLSv1, TLSv1.1, TLSv1.2). The default setting <literal>all -SSLv2</literal> means that all the protocols will be supported except SSLv2. You could go in and individually specify the individual protocols but this setting makes it future-proof. When TLSv1.3 is released and supported by OpenSSL you won't have to change anything; your system will automatically start supporting TLSv1.3. Unless you have a good reason to do so it's recommended that you leave this setting the way it is.
<screen>
# SSL Cipher Suite:
# List the ciphers that the client is permitted to negotiate.
# See the mod_ssl documentation for a complete list.
SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5
</screen>
The setting everyone seems to care about. What symmetric ciphers will your webserver will use is determined here. The default setting should probably be hardened a bit by removing <literal>MEDIUM</literal> from the list. All current operating systems and browsers support <literal>HIGH</literal> ciphers which offer the best protection. The <literal>!aNULL</literal> removes unauthenticated cipher options and the <literal>!MD5</literal> removed any cipher that utilizes the <literal>MD5</literal> hash which is quite weak and should be avoided.
<screen>
# Speed-optimized SSL Cipher configuration:
# If speed is your main concern (on busy HTTPS servers e.g.),
# you might want to force clients to specific, performance
# optimized ciphers. In this case, prepend those ciphers
# to the SSLCipherSuite list, and enable SSLHonorCipherOrder.
# Caveat: by giving precedence to RC4-SHA and AES128-SHA
# (as in the example below), most connections will no longer
# have perfect forward secrecy - if the server's key is
# compromised, captures of past or future traffic must be
# considered compromised, too.
#SSLCipherSuite RC4-SHA:AES128-SHA:HIGH:MEDIUM:!aNULL:!MD5
</screen>
These are settings that are for those that want speed over security. If you are concerned with processor time for decrypting data you can comment out the above <literal>SSLCipherSuite</literal> line and use this one. It is highly recommended that you remove the <literal>RC4-SHA</literal> as RC4 should no longer be used. The prioritization of <literal>AES128-SHA</literal> above all other ciphers means that the hardware accelerator will be most efficient with most clients.
<screen>
#SSLHonorCipherOrder on
</screen>
This should be uncommented and used no matter your configuration for security or speed. This setting makes the client connect to the first cipher they can which makes for the most secure or fastest (depending on your settings) happen more often.
<screen>
# Server Certificate:
# Point SSLCertificateFile at a PEM encoded certificate. If
# the certificate is encrypted, then you will be prompted for a
# pass phrase. Note that a kill -HUP will prompt again. A new
# certificate can be generated using the genkey(1) command.
SSLCertificateFile /etc/pki/tls/certs/localhost.crt
# Server Private Key:
# If the key is not combined with the certificate, use this
# directive to point at the key file. Keep in mind that if
# you've both a RSA and a DSA private key you can configure
# both in parallel (to also allow the use of DSA ciphers, etc.)
SSLCertificateKeyFile /etc/pki/tls/private/localhost.key
# Server Certificate Chain:
# Point SSLCertificateChainFile at a file containing the
# concatenation of PEM encoded CA certificates which form the
# certificate chain for the server certificate. Alternatively
# the referenced file can be the same as SSLCertificateFile
# when the CA certificates are directly appended to the server
# certificate for convinience.
#SSLCertificateChainFile /etc/pki/tls/certs/server-chain.crt
# Certificate Authority (CA):
# Set the CA certificate verification path where to find CA
# certificates for client authentication or alternatively one
# huge file containing all of them (file must be PEM encoded)
#SSLCACertificateFile /etc/pki/tls/certs/ca-bundle.crt
</screen>
These are where your certificates live. You may have to update the name of the certificate and key files but the files should live in the directories provided.
<screen>
# Client Authentication (Type):
# Client certificate verification type and depth. Types are
# none, optional, require and optional_no_ca. Depth is a
# number which specifies how deeply to verify the certificate
# issuer chain before deciding the certificate is not valid.
#SSLVerifyClient require
#SSLVerifyDepth 10
</screen>
These are settings for requiring certificate authentication from the client as well. Use this to add additional security to your site by validating certificates on the client side.
</para>
</section>
</chapter>