Handling Secure Sites

One feature that's often used in conjunction with scripting is encryption. More precisely, the Secure Sockets Layer (SSL) is an encryption protocol that can be used to encrypt data that pass between the Web server and Web browser to protect the data from prying eyes. SSL is frequently used on e-commerce sites and others that handle sensitive data. Apache is capable of handling SSL encryption, but only with the addition of supplemental software. There are various implementations of SSL for Apache, such as the Apache-SSL project (http://www.apache-ssl.org), mod_ssl (http://www.modssl.org), and various commercial sources.

Understanding SSL

SSL is a form of encryption technology that's similar to that used in the Secure Shell (SSH) remote login protocol. (In fact, the popular OpenSSH package relies on the OpenSSL package, which is also used by some SSL-enabled Apache implementations.) In terms of Web transfers, SSL was designed to solve two problems:

• Encryption ” SSL allows both sides of a connection to encrypt data in order to keep it private. This is obviously important for transmitting sensitive information such as credit card numbers or bank account numbers . Encryption alone can be handled by using public-key cryptography, which requires two keys on each side of the connection. Each party encrypts data with the other's public key. The encrypted data can only be decrypted with the matching private key, so the sender can be sure that only the recipient can decode the data.

• Authentication ” Even with encryption, there is risk involved in sending sensitive data across the Internet. One such risk is that the other server may not be what it claims to be. For instance, if you type http://www.abigretailer.com into your Web browser, how can you be sure that you've actually reached the claimed retailer? It's conceivable that a miscreant has adjusted a DNS server to redirect requests for the legitimate retailer to a bogus site, or has modified routers to the same end. SSL provides a mechanism for authenticating parties in an exchange by relying upon a third party, known as a certificate authority (CA). The CA provides certificates, which are digital codes used in creating public keys. If one party uses a certificate from a CA, the second party can verify the identity of the first with a high degree of confidence. (This isn't perfect, though; for instance, there was a foul-up in 2001 involving certificates that were mistakenly issued in Microsoft's name to somebody who was not affiliated with Microsoft.) Normally, secure Web servers will need certificates from a valid CA to reassure users that the site is valid.

NOTE

You can serve as your own CA, but this doesn't provide good authentication except for internal uses, since outsiders can't trust that your internally generated certificates are valid. If you want to run an e-commerce site, as a practical matter you'll need to obtain certificates from a CA. One list of CAs is available at http://www.apache-ssl.org/#Digital_Certificates. Individuals browsing the Web don't usually need certificates from a CA because Web sites seldom need to be sure they're communicating with the claimed individual.

SSL encryption isn't normally done on the usual HTTP port (80). The default port for secure HTTP (or HTTPS ) transfers is 443. You can tell a Web browser to use this port by using https:// at the start of the URL rather than http:// . When you configure Apache to use SSL, you'll have to either run one server that binds to both ports and treats them differently, or run two servers, one for each port. The former is usually the simpler approach, but if for some reason you want to run two different types of servers (such as Apache for secure requests and thttpd for normal requests), you can do so.

Configuring SSL

The first step in using SSL with Apache is to install and configure an SSL package. There are two SSL packages in common use in Linux:

• SSLeay (http://www2.psy.uq.edu.au/~ftp/Crypto/ssleay/)

• OpenSSL (http://www.openssl.org)

OpenSSL is rapidly becoming the standard in Linux. (OpenSSL is actually derived from SSLeay, but SSLeay remains available as a separate package.) It's included in many Linux distributions, including Debian, Mandrake, Red Hat, and SuSE. SSLeay and OpenSSL are logically equivalent; they function in the same way, although different packages sometimes place configuration files in different locations, and their main binaries are named differently ( ssleay and openssl , respectively).

Once OpenSSL is installed, you need to obtain a certificate for it. For a public site, you should obtain your certificate through a CA, so that your users know you are who you claim to be. For testing purposes or to run a private site, though, you can use a certificate that you generate yourself. In fact, some Apache SSL installation scripts, like the one that ships with Debian, create such a certificate automatically. If yours doesn't, you can use a command like the following to do the job:

 #  openssl req $@ -new -x509 -nodes \   -config /usr/share/doc/apache-ssl/examples/ssleay.cnf  \   -out /etc/apache-ssl/apache.pem \   -keyout /etc/apache-ssl/apache.pem  

NOTE

The preceding command assumes that the SSL-enabled Apache's configuration files will reside in /etc/apache-ssl and that an SSL example configuration file exists at /usr/share/doc/apache-ssl/examples/ssleay.cnf . You may need to change these values to suit your configuration. This command also uses backslashes ( \ ) to indicate continuations of long lines. You can leave these in or omit them and type the entire command on one line.

When you type this command, openssl prompts for some information, such as your location and computer name. This information will be encoded in the certificate, which will reside in the /etc/apache-ssl/ apache.pem file.

If you obtain a certificate from a CA, you should replace your self-generated certificate file with whatever file your CA gives you. This should eliminate the warning message that users will see if they try to access a site that uses a self-generated certificate. Figure 20.2 shows one such warning message, as displayed by Opera in Linux; other browsers may format the information differently or present it across multiple dialog boxes.

Figure 20.2. If you use a self-generated certificate, users who access your site will see a warning that the certificate has expired or is not recognized.

Enabling SSL in Apache

In principle, Apache can be configured to use SSL through an add-on module. In practice, though, the SSL module requires a few changes to the Apache server, so some SSL-enabled Apache packages provide a rebuilt Apache server along with the SSL extensions. Other distributions release an Apache package that was built with the SSL hooks, and provide an SSL extension package that works with the standard Apache package. If you try to mix and match regular Apache and SSL-enabled Apache packages, the combination might or might not work.

Many SSL packages use a separate configuration file for the SSL-enabled server than for the standard server. For instance, Debian's SSL- enabled Apache configuration files reside in /etc/apache-ssl , whereas the standard Debian Apache files are in /etc/apache . The configuration files are largely the same as those for Apache without SSL support, so you should set details like the Web site directories in the same way. Some specific options you might need to change compared to a regular installation include the following:

• ServerType ” SSL-enabled versions of Apache must be run standalone, not from a super server. Therefore, ServerType must be standalone .

• Port ” The standard SSL HTTP port is 443, so you should set this value appropriately. Listen may also bind the server to a specific port number, and so should be adjusted, if used.

• Modules ” The LoadModule and AddModule directives may reference one or more modules related to SSL. These should be set correctly in the default or example configuration file for any SSL-enabled version of Apache.

• SSLRequireSSL ” You might use this option within a <Directory> directive to block access to a directory if the client isn't using SSL. You use this directive alone (it takes no options). This can be a convenient way to ensure that sensitive data aren't transferred without encryption, but of course you'll also need some other form of access control to ensure that only authorized users can reach the directory.

• SSLEnable ” This directive enables SSL. Like SSLRequiresSSL , it takes no options; just list it on a line of its own.

• SSLCACertificatePath ” This directive points Apache to the directory in which the certificate is stored, such as /etc/apache-ssl .

• SSLCertificateFile ” This directive points Apache to the SSL certificate file, such as /etc/apache-ssl/apache.pem .

There are several other SSL-related directives you can set. Consult the comments in the configuration file, your SSL-enabled Apache's documentation, or a book that covers SSL Apache configuration for details.

Once you've configured SSL and Apache, you can start the SSL-enabled Apache server. You should then be able to reach the server by typing https:// rather than http:// in a URL for the server. If you've generated your own certificate, you'll probably see a warning like the one in Figure 20.2. You can accept the certificate (some browsers give you several options for the conditions in which they'll accept this certificate in the future) to continue testing the Web site.

WARNING

As a general rule, you shouldn't accept unverified certificates from random Web servers. Most Web sites that use SSL register with a CA, and you should not see such warnings for these sites. If you do, it may mean that the Web site operator has allowed the certificate to lapse (they are time-limited) or that the operator hasn't registered with a CA. It could also mean that somebody is attempting to masquerade as the Web site, and hopes to dupe users into relinquishing sensitive data like credit card numbers.