Web Server Security: SSL

Web server security deals with two different tasks: protecting your Web server from unauthorized access, and providing security for transactions carried out between a Web browser client and your Web server. To protect your server from unauthorized access, you use a proxy server such as Squid. Squid is a GNU proxy server often used with Apache on Linux systems. (See Chapter 23 for a detailed explanation of the Squid server.) Apache itself has several modules that provide security capabilities. These include mod_access for mandatory controls; mod_auth, mod_auth_db, mod_auth_digest, and mod_auth_dbm, which provide authentication support; and mod_auth_anon for anonymous FTP-like logging (see previous sections on access control and authentication).

To secure transmissions, you need to perform three tasks. You have to verify identities, check the integrity of the data, and ensure the privacy of the transmission. To verify the identities of the hosts participating in the transmission, you perform authentication procedures. To check the integrity of the data, you add digital signatures containing a digest value for the data. The digest value is a value that uniquely represents the data. Finally, to secure the privacy of the transmission, you encrypt it. Transactions between a browser and your server can then be encrypted, with the browser and your server alone able to decrypt the transmissions. The protocol most often used to implement secure transmissions with Linux Apache Web servers is the Secure Sockets Layer (SSL) protocol, which was originally developed by Netscape for secure transactions on the Web.

Like the Secure Shell (SSH) described in Chapter 18 and GPG discussed in Chapter 16, SSL uses a form of public- and private-key encryption for authentication. Data is encrypted with the public key but can be decrypted only with the private key. Once the data is authenticated, an agreed-upon cipher is used to encrypt it. Digital signatures encrypt an MD5 digest value for data to ensure integrity. Authentication is carried out with the use of certificates of authority. Certificates identify the different parties in a secure transmission, verifying that they are who they say they are. A Web server will have a certificate verifying its identity, verifying that it is the server it claims to be. The browser contacting the server will also have a certificate identifying who it is. These certificates are, in turn, both signed by a certificate authority, verifying that they are valid certificates. A certificate authority is an independent entity that both parties trust.

A certificate contains the public key of the particular server or browser it is given to, along with the digital signature of the certificate authority and identity information such as the name of the user or company running the server or browser. The effectiveness of a certificate depends directly on the reliability of the certificate authority issuing it. To run a secure Web server on the Internet, you should obtain a certificate from a noted certificate authority such as Verisign. A commercial vendor such as Stronghold can do this for you. Many established companies already maintain their own certificate authority, securing transmissions within their company networks. An SSL session is set up using a handshake sequence in which the server and browser are authenticated by exchanging certificates, a cipher is agreed upon to encrypt the transmissions, and the kind of digest integrity check is chosen. There is also a choice in the kind of public key encryption used for authentication, either RSA or DSA. For each session, a unique session key is set up that the browser and server use.

A free Open Source version of SSL called OpenSSL is available for use with Apache (see www.openssl.org). It is based on SSLeay from Eric A. Young and Tim J. Hudson. However, U.S. government restrictions prevent the Apache Web server from being freely distributed with SSL capabilities built in. You have to separately obtain SSL and update your Apache server to incorporate this capability.

The U.S. government maintains export restrictions on encryption technology over 40 bits. SSL, however, supports a number of ciphers using 168-, 128-, and 40-bit keys (128 is considered secure, and so by comparison the exportable 40-bit versions are useless). This means that if Apache included SSL, it could not be distributed outside the United States. Outside the United States, however, there are projects that do distribute SSL for Apache using OpenSSL. These are free for noncommercial use in the United States, though export restrictions apply. The Apache-SSL project freely distributes Apache with SSL built in, apache+ssl. You can download this from their Web site at www.apache-ssl.org (though there are restrictions on exporting encryption technology, there are none on importing it). In addition, the mod_ssl project provides an SSL module with patches you can use to update your Apache Web server to incorporate SSL (www.modsll.org). mod_ssl is free for both commercial and noncommercial use under an Apache-style license. Red Hat includes the mod_ssl module with its distribution in the mod_ssl package (/etc/httpd/conf.d/ssl.conf configuration file).

The mod_ssl implementation of SSL provides an alternate access to your Web server using a different port (443) and a different protocol, https. In effect, you have both an SSL server and a nonsecure version. To access the secure SSL version, you use the protocol https instead of http for the Web server's URL address. For example, to access the SSL version for the web server running at www.mytrek.com, you would use the protocol https in its URL, as shown here:

https://www.mytrek.com

You can configure mod_ssl using a number of configuration directives in the Apache configuration file, smb.conf. On Red Hat, the default configuration file installed with Apache contains a section for the SSL directives along with detailed comments. Check the online documentation for mod_ssl at www.modssl.org for a detailed reference listing all the directives. There are global, server-based, and directory-based directives available.

In the Red Hat smb.conf file, the inclusion of SSL directives are controlled by IfDefine blocks enabled by the HAVE_SSL flag. For example, the following code will load the SSL module:

<IfDefine HAVE_SSL>
LoadModule ssl_module     modules/libssl.so
</IfDefine>

The SSL version for your Apache Web server is set up in the smb.conf file as a virtual host. The SSL directives are enabled by an ifDefine block using the HAVE_SSL flag. Several default directives are implemented such as the location of SSL key directories and the port that the SSL version of the server will listen on (443). Others are commented out. You can enable them by removing the preceding # symbol, setting your own options. Several of the directives are shown here:

<IfDefine HAVE_SSL>
## SSL Virtual Host Context
   
#  Server Certificate:
SSLCertificateFile /etc/httpd/conf/ssl.crt/server.crt
   
#  Server Private Key:
SSLCertificateKeyFile /etc/httpd/conf/ssl.key/server.key
   
#  Certificate Authority (CA):
#SSLCACertificatePath /etc/httpd/conf/ssl.crt
#SSLCACertificateFile /etc/httpd/conf/ssl.crt/ca-bundle.crt

In the /etc/httpd/conf directory, mod_ssl will set up several SSL directories that will contain SSL authentication and encryption keys and data. The ssl.crt directory will hold certificates for the server. The ssl.key directory holds the public and private keys used in authentication encryption. Revocation lists for revoking expired certificates are kept in ssl.crl. The ssl.csr directory holds the certificate signing request used to request an official certificate from a certificate authority. ssl.prm holds parameter files used by the DSA key encryption method. Check the README files in each directory for details on the SSL files they contain.

The mod_ssl installation will provide you with a demonstration certificate called snakeoil that you can use to test your SSL configuration. When you have an official certificate, you can install it with the make certificate command within the ssl.crt directory. This will overwrite the server.crt server certificate file.