IN THIS CHAPTER
“The only system that is truly secure is one that is switched off and unplugged, locked in a titanium-lined safe, buried in a concrete bunker, and surrounded by nerve gas and very highly-paid armed guards. Even then, I wouldn't stake my life on it.” | ||
| --Gene Spafford | ||
This chapter presents you with the security technologies involved in conducting secure transactions over the Internet. It explains the installation and configuration of mod_ssl, the SSL protocol module for Apache 2.0. SSL stands for Secure Socket Layers and enables Web browsers and servers to protect their communications. Configuring a secure server is a complex task and requires an understanding of the underlying protocols. The chapter starts with an introduction to several security-related concepts and algorithms. If you are already familiar with this background material you can skim through the initial sections. Later sections explain the steps necessary to get SSL up and running with Apache 2.0. Pointers to useful resources are provided at the end of the chapter.
As the Internet grows and Web technologies evolve an increasing number of business and individuals use this global network to conduct financial transactions and transmit sensitive information. Hence, the parties need to protect these communications from potential attackers.
The threats are easy to understand, but the solutions can be fairly complex. Consider the typical scenario in which an individual wants to buy a book online. Let's call this person Alice (this is a convention started in one of the original academic cryptographic papers, where Alice and Bob are two figured individuals trying to communicate securely).
Note
For more information on these papers you can refer to Rivest, R.L., Shamir, A., and Adleman, L.M., “On Digital Signatures and Public Cryptosystems” Technical Report, MIT Laboratory for Coumputer Science, January 1979. These are the fathers of public key cryptography, and invented the RSA algorithm, named after them.
To buy a book, Alice needs to transmit her credit-card number to the book merchant, but she does not want an attacker to be able to intercept this information. With this information confidentiality needs to be protected. Alice wants to make sure the attacker cannot successfully modify or replay her order so she does not end up with a different book or several instances of the same book. The integrity of the information needs to be preserved. Finally, Alice wants to make sure that she is communicating with the legitimate merchant Web site, and not a rogue Web site set up by an attacker. She needs to authenticate the identity of the remote end. Cryptography studies the algorithms and methods used to securely transmit messages to ensure confidentiality, integrity, and authenticity.
Encryption is a common method of guaranteeing the confidentiality of an electronic message transmitted over an insecure network. The original message (plaintext) is converted by the sender into a new, encrypted, message (ciphertext) using a certain piece of information (key). The receiver can then use his own key to convert the ciphertext to the original message. The ciphertext looks like random data to an attacker. Only someone with the appropriate key can decrypt that message and make sense out of it.
If the key used to encrypt and decrypt the message is the same then the process is known as symmetric cryptography. DES, Triple-Des, RC4 and RC2 are algorithms used for symmetric key cryptography. Many of these algorithms can have different key sizes, measured in bits. In general, given an algorithm, the greater the number of bits of the key, the more secure the algorithm is and the slower it will run, because of the increased computational needs of performing the algorithm.
Key distribution is the main problem with symmetric cryptography. The encryption/decryption key is a shared secret between sender and receiver and needs to be securely transmitted to both parties. Public key cryptography takes a different approach. Instead of both parties sharing the same key, there is a pair of keys, one public, and the other private. The public key can be widely distributed, whereas the owner keeps the private key secret. These two keys are complementary; a message encrypted with one of the keys can only be decrypted by the other.
Anyone wanting to transmit a secure message to you can encrypt the message using your public key; assured that only the owner of the private key, you, can decrypt it. Even if the attacker has access to the public key, he cannot decrypt the communication. In fact, you want the public key to be as widely available as possible. Public key cryptography can also be used to provide message integrity and authentication. RSA is the most popular public key algorithm.
The assertion that “only the owner of the private key can decrypt it” means that with the current knowledge of cryptography and availability of computing power, an attacker will not be able to break the encryption by brute force alone. If the algorithm or its implementation are found to be flawed, then realistic attacks are possible.
Note
Public key cryptography is similar to giving away many identical lockpads and retaining the key that opens them all. Anybody who wants to send you a message privately can do so by putting it in a safe and locking it with one of those lockpads (public keys) before sending it to you. Only you have the appropriate key (private key) to open that lockpad (decrypt the message).
A message digest is a method to create a fixed-length representation of an arbitrary message that uniquely identifies it. You can think of it as the fingerprint of the message. A good message digest algorithm should be irreversible and collision-resistant: Irreversible means that the original message cannot be obtained from the digest and collision-resistant that no two different messages should have the same digest.
Message digests alone, however, do not guarantee the integrity of the message, because an attacker could change the text and the message digest. Examples of digest algorithms are MD5 and SHA.
Message Authentication Codes, or MACs, are similar to message digests, but incorporate a shared secret key in the process. The result of the algorithm depends both on the message and the key used. Because the attacker has no access to the key, he cannot modify both the message and the digest. HMAC is an example of a message authentication code algorithm.
Note
To help you understand what a digest is, think about the following primitive digest algorithm—take a text and assign a number to each letter in the text. The number corresponds to the place it occupies in the alphabet (a=1, b=2, and so on). Add all the numbers. The resulting number is a digest of that message. If you modify the message the digest changes. This is just a simple example and the algorithm is not practical. Although you cannot reconstruct the original message from that number, it is feasible to carefully modify the original message while keeping the number constant. The algorithms used in practice are much more sophisticated and secure for all practical purposes.
Public key cryptography can be used to digitally “sign” messages. In fact, just by encrypting a message with your secret key the receiver can guarantee it came from you. Other digital signature algorithms involve first calculating a digest of the message and then signing the digest.
Thanks to digital signatures, you can tell that the person who created that public and private key pair is the one sending the message. But how can you know that person is the one you think he is? An attacker could impersonate his identity and distribute a different public key, claiming it is the legitimate one. It is necessary to have a mechanism that links an individual or organization with its public key. This is achieved by using digital certificates. Digital certificates are electronic documents that contain a public key and information about its owner (name, address, and so on). To be useful, the certificate needs to be signed by a trusted third party (Certification Authority). There are many different kinds of Certificate Authorities, as described later on the chapter. Some of them are commercial entities, providing certification services to companies conducting business over the Internet. Others are created by companies looking to provide internal certification services.
The Certification Authority guarantees that the information in the certificate is correct and that the key belongs to that individual or organization. Certificates have a period of validity and can expire or be revoked. Finally, certificates can be chained. That means that the certification process can be delegated. For example, a trusted entity can certify companies, which in turn can certify their own employees.
If this whole process is to be effective and trusted, the Certificate Authority must require appropriate proof of identity from individuals and organizations before it issues a certificate.
We have seen how confidentiality can be achieved via encryption, integrity via message authentication codes, and authentication via certificates and digital signatures. These concepts have been incorporated into the SSL protocol to enable secure communications on the Internet. The next section explains in detail the inner workings of SSL.
In this section you will learn how encryption, digital signatures, and certificates all work together to provide Alice with a secure shopping experience.
Note
TLS stands for Transport Layer Security. SSL and TLS is a family of protocols originally designed for securing communications based on the HTTP protocol, but they can be used to protect a variety of other protocols. Netscape released SSL version 2 in 1994 and SSL version 3 in 1995. TLS is an IETF standard designed to standardize SSL as an Internet protocol. It is mostly just a modification of SSL version 3 with a small number of added features and minor cleanups. The name TLS is the result of some silly politics between Microsoft and Netscape over the naming of the protocol.
The requirement for SSL connections is indicated by replacing the http scheme in URLs with https (for HTTP over SSL). Examples of such URLs are https://www.modssl.org, https://www.ibm.com, or https://www.microsoft.com. The default port for HTTPS is 443.
The browser will tell you when a secure connection has been established—Netscape and Microsoft browsers will show a small locked padlock in one of the lower corners. The next section explains the details of the SSL protocol.
When Alice's browser wants to send an encrypted request to a secure server, it first establishes a secure channel based on SSL. It then communicates using HTTP over this connection.
An SSL connection is divided into two phases, the handshake and data transfer phases. The handshake enables Alice to authenticate the remote server and agree on a set of keys to be used for encrypting the information in the data transfer phase.
The handshake process is the following:
The browser sends an initial request with information about the protocol version and algorithms supported. The request includes a random number—r1.
The server answers with information about the algorithms to be used, a server certificate, and a random number r2.
The browser makes sure the certificate is valid. It then generates a secret string r3, which is encrypted, using the server public key found in the certificate.
Both browser and server use r1, r2, and r3 to compute the symmetric encryption keys and the MAC keys using what is called a key-exchange algorithm.
The browser calculates a MAC of all the handshake messages and sends it to the server.
The server does the same and transmits it to the browser.
The last two steps are necessary to prevent an attacker from manipulating the handshake phase itself (for example by intercepting the messages and modifying the set of algorithms server and client agree to use). Certificate contents and verification are explained in more detail in later sections of this chapter.
During the data transfer phase, HTTP messages are divided into individual pieces. A MAC is calculated and encrypted together with the fragment that is then transmitted. The message is received at the other end, decrypted, and the MAC is calculated.
By using the SSL protocol, Alice achieves:
Confidentiality: After the handshake phase, sender and receiver have agreed on a secret key that they can use to encrypt the data being transmitted, such as Alice's credit card.
Integrity: SSL messages are transmitted together with MACs that prevent them from being altered or replayed. So Alice does not end up buying ten copies of the same book.
Authentication: The server provides Alice with a certificate that provides information about the company or individual running the remote site. Alice can validate the certificate checking that the certificate has been issued or signed by a Certificate Authority that she trusts. The certificates of several well-known CAs are included by default in Microsoft and Netscape browsers.
Note
If a certificate has expired, does not match the name of the host you are accessing, or otherwise is invalid, the browser will pop up a window asking you if you still want to connect.
A properly configured SSL server helps secure the communication between a browser and a server. But security can still be compromised in a variety of other ways. An attacker can gain remote access to the server machine and modify the application logic that handles the credit-card transactions. Those credit-card numbers themselves could be stored in an SQL database connected to the Internet with a default password. The attacker could have physical access to the client machine and install a modified version of the browser or a key-logging program.
SSL is an important component of a secure-Internet infrastructure but by no means is the only one. An attacker will always choose the weakest link in your security infrastructure to try to break in into your systems.
SSL support for Apache is provided by mod_ssl, a module included with Apache 2.0. mod_ssl requires the OpenSSL library. OpenSSL is an open source implementation of the SSL/TLS protocols and a variety of other cryptographic algorithms. OpenSSL is based on the SSLeay library developed by Eric A. Young and Tim J. Hudson. You can learn more about mod_ssl and OpenSSL in the Web sites noted in the reference at the end of the chapter.
This section explains how to download and install the OpenSSL toolkit for both Windows and Unix variants.
The required OpenSSL libraries are included with the Windows installer of Apache 2.0 and no further installation or download is necessary. openssl.exe is included in the bin/ directory of the Apache distribution. It is a utility for generating certificates, keys, certificate signing requests, and so on.
If you are running a recent Linux or FreeBSD distribution, OpenSSL might already be installed in your system. Use the package management tools bundled with your distribution to determine if that is the case or install it otherwise
OpenSSL can be downloaded from http://www.openssl.org. After you have downloaded the software, you need to uncompress it and change into the created directory:
# gunzip < openssl*.tar.gz | tar xvf - # cd openssl*
OpenSSL contains a config script to help you build the software. You need to provide the path to which the software will install. The path we use in this chapter is /usr/local/ssl/install, and you probably need to have superuser privileges to install the software there. You can install the software as a regular user, but to do so you will need to change the path. Then you need to build and install the software:
# ./config --prefix=/usr/local/ssl/install --openssldir=/usr/local/ssl/install/openssl # make # make install
If everything goes well, you have now successfully installed the OpenSSL toolkit. The openssl command-line tool will be located in /usr/local/ssl/install/bin/.
This tool is used to create and manipulate certificates and keys and its usage is described in a later section on certificates.
SSL extensions for Apache 1.3 needed to be distributed separately because of export restrictions. These restrictions no longer exist and mod_ssl is bundled and integrated with Apache 2.0. This section describes the steps necessary to build and install this module. mod_ssl depends on the OpenSSL library, so a valid OpenSSL installation is required.
You can download a binary distribution of Apache 2.0 for the Windows platform from http://www.apache.org that includes mod_ssl.
If you are using the Apache 2.0 server that came installed with your operating system, chances are it already includes mod_ssl. Use the package management tools bundled with your distribution to install mod_ssl if it is not present in the system.
When you build Apache 2.0 from source you need to pass the following options to enable and build mod_ssl:
--enable-ssl -with-ssl=/usr/local/ssl/install/openssl
This assumes you installed OpenSSL in the location described in previous sections.
If you compiled mod_ssl statically into Apache you can check if it is present by issuing the following command, which provides a list of compiled in modules:
# ./usr/local/apache2/bin/httpd -l
The command assumes you installed Apache in the /usr/local/apache2 directory.
We have seen in previous sections the role certificates play in SSL. In this section we explain in detail the information contained in a certificate and how to create and manage certificates and keys using the openssl command-line tool.
The main standard for certificates is X.509, adapted for Internet usage. A certificate contains information about:
The issuer is the name of the signer of the certificate.
The subject is the person holding the key being certified.
The subject public key is the public key of the subject.
Control information such as the dates in which the certificate is valid.
Signature is the signature that covers the previous data.
You can check a real-life certificate by connecting to a secure server with your browser. You can click the locked padlock icon to open information on the SSL connection. You can open the property pages by clicking on File, Properties, Certificates. Netscape browsers provide a similar interface.
Open the https://www.ibm.com URL in your browser and analyze the certificate, following the steps outlined in the above paragraph. You can see how the issuer of the certificate is the Equifax Secure E-business Certification Authority, which in turn has been certified by the Thawte CA. The page downloaded seamlessly because Thawte is a trusted CA that has its own certificates bundled with Internet Explorer and Netscape Navigator.
To check which are the certificates bundled with your Internet Explorer browser, go to the top menu and select Tools, Internet Options, Content, Certificates, Trusted Root Certification Authorities.
You can see that both issuer and subject are provided as distinguished names (DN), a structured way of providing a unique identifier for every element on the network. In the case of the IBM certificate, the DN is C=US, S=New York, L=Armonk, O=IBM, CN=www.ibm.com.
C stands for Country, S for State, L for Locality, O for organization and CN for Common Name. In the case of a Web site certificate the common name identifies the fully qualified domain name of the Web site (FQDN). This is the server name part of the URL, in this case www.ibm.com. If this does not match what you typed in the top bar, the browser will issue an error.
You now need to learn to use the openssl command-line tool to create and manage keys and certificates. It assumes OpenSSL was installed in the path described in the OpenSSL installation section. The examples refer to the Unix version. All the steps work the same for Windows you just need to use openssl.exe instead.
We need to have a public/private key pair before we can create a certificate request. We assume the FQDN for the certificate you want to create is www.yourdomain.com. (You will need to substitute this name for the FQDN of the machine you have installed Apache on). You can create the keys by issuing the following command:
# ./usr/local/ssl/install/bin/openssl genrsa -des3 -rand file1:file2:file3 -out www.yourdomain.com.key 1024
genrsaindicates to OpenSSL that we want to generate a key pair.des3indicates that the private key should be encrypted and protected by a pass phrase.The
randswitch is used to provide OpenSSL with random data to assure that the generated keys are unique and unpredictable. Select several large, relatively random files for this purpose (such as compressed log files, kernel image, and so on). This switch is not necessary on Windows, because the random data is automatically generated by some other means.The
outswitch indicates where to store the results.1024indicates the number of bits of the generated key.
The result of this command looks like
625152 semi-random bytes loaded Generating RSA private key, 1024 bit long modulus .....++++++ .........................++++++ e is 65537 (0x10001) Enter PEM pass phrase: Verifying password - Enter PEM pass phrase:
As you can see, you will be asked to provide a pass phrase. Choose a secure one. The pass phrase is necessary to protect the private key and you will be asked for it whenever you want to start the server. You can choose not to protect the key. This is convenient because you will not need to enter the pass phrase during reboots, but it is highly insecure and a compromise of the server means a compromise of the key as well. In any case, you can choose to unprotect the key either by leaving the -des3 switch out in the generation phase or by issuing the following command:
# ./usr/local/ssl/install/bin/openssl rsa -in www.yourdomain.com.key -out www.yourdomain
It is a good idea to backup the www.yourdomain.com.key file. You can learn about the contents of the key file by issuing the following command:
# ./usr/local/ssl/bin/openssl rsa -noout -text -in www.yourdomain.com.key
To get a certificate issued by a CA you need to submit what is called a Certificate Signing Request. To create the request, issue the following command:
# ./usr/local/ssl/install/bin/openssl req -new -key www.yourdomain.com.key -out www.yourdomain.com.csr
You will be prompted for the certificate information:
Using configuration from /usr/local/ssl/install/openssl/openssl.cnf Enter PEM pass phrase: You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]:US State or Province Name (full name) [Some-State]:CA Locality Name (eg, city) []: San Francisco Organization Name (eg, company) [Internet Widgits Pty Ltd]:. Organizational Unit Name (eg, section) []:. Common Name (eg, YOUR name) []:www.yourdomain.com Email Address []:[email protected] Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []:
The certificate is now stored in www.yourdomain.com.csr. You can learn about the contents of the certificate via the following command:
# ./usr/local/ssl/install/bin/openssl req -noout -text -in www.yourdomain.com.csr
You can submit the certificate signing request file to a CA for processing. Verisign and Thawte are two of those CAs. You can learn more about their particular submission procedures at their Web sites:
Verisign: http://digitalid.verisign.com/server/apacheNotice.htm
You can also create a self-signed certificate. That is, you are going to be the issuer and the subject of the certificate. Although this is not very useful for a commercial Web site, it will allow you to test your installation of mod_ssl or to have a secure Web server while you wait for the official certificate from the CA.
# ./usr/local/ssl/install/bin/openssl x509 -req -days 30 -in www.yourdomain.com.csr -signkey www.yourdomain.com.key -out www.yourdomain.com.cert
You need to copy your certificate www.yourdomain.com.cert (either the one returned by the CA or your self signed one) to /usr/local/ssl/install/openssl/certs/ and your key to /usr/local/ssl/install/openssl/private/.
You need to protect your key file by issuing the following command:
# chmod 400 www.yourdomain.key
In the previous sections we have introduced the (not so basic) concepts behind SSL and you have learned how to generate keys and certificates. Now, finally, you can configure Apache to support SSL. mod_ssl needs either to be compiled statically or, if you have compiled as a loadable module, the appropriate LoadModule directive needs to be present in the file.
Add the following configuration snippet to your Apache configuration file:
Listen 80 Listen 443 <VirtualHost _default_:443> ServerName www.yourdomain.com SSLEngine on SSLCertificateFile /usr/local/ssl/install/openssl/certs/www.yourdomain.com.cert SSLCertificateKeyFile /usr/local/ssl/install/openssl/certs/www.yourdomain.com.key </VirtualHost>
With the previous configuration, we setup a new virtual host that will listen in port 443 (the default port for HTTPS) and we enable SSL on that virtual host.
You will need to tell the server the location of the certificate and the file containing the associated key. We do so using SSLCertificateFile and SSLCertificateKeyfile directives.
Now you can stop the server if it was running, and start it again. If your key is protected by a pass phrase you will be prompted for it. After this, Apache will start and you should be able to connect securely to it via the https://www.yourdomain.com/ URL.
If you are unable to restart your server, check the Apache error log for clues to what might have gone wrong. For example, if you cannot bind to the port make sure that Apache is not running somewhere else. You need to have administrator privileges to bind to port 443, otherwise change the port to 8443 and access the URL via https://www.yourdomain.com:443.
mod_ssl provides a comprehensive technical reference documentation. We are not going to reproduce that information here, but rather explain what is possible and which configuration directives you need to use. You can then refer to the online documentation at http://www.modssl.org for the specific syntax or options.
You can control which ciphers and protocols are used via the SSLCipherSuite and SSLProtocol commands. For example, you can configure the server to use only strong encryption with the following configuration:
SSLProtocol all SSLCipherSuite HIGH:MEDIUM
Similar to how clients can verify the identity of servers using server certificates, servers can verify the identity of clients by requiring a client certificate and making sure it is valid.
SSLCACertificateFile and SSLCACertificatePath are two Apache directives used to specify trusted CAs. We can then use SSLVerifyClient to restrict access to clients certified by these CAs.
SSL is a protocol that requires intensive calculations. mod_ssl and OpenSSL allow several ways to speed up the protocol by caching some of the information about the connection (this can be configured using the SSLcache, SSLCachetimeout directives), and by providing support for specialized cryptographic hardware to perform CPU intensive computations.
mod_ssl hooks up into Apache's logging system and provides support for logging any SSL-related aspect of the request, ranging from the protocol used to the information contained in specific elements of a client certificate. This information can also be passed to CGI scripts via environment variables. SSLLog and SSLLogLevel allow you to specify where to store SSL- specific errors and which kind of errors to log.
Many of these options can be applied in a per-directory or per-location basis. The SSL parameters might be renegotiated for those URLs. This can be controlled via the SSLoptions directive.
A common problem for people is how to make name-based virtual hosts work with SSL. The answer is that you can't. Name-based virtual hosts depend on the Host header of the HTTP request, but the certificate verification happens when the SSL connection is being established and no HTTP request can be sent. There is a protocol for upgrading an existing HTTP connection to TLS, but it is mostly unsupported by current browsers (RFC 2817).
The book on cryptography:
Applied Cryptography, Second Edition, by Bruce Schneier 0471117099
An excellent book on the SSL protocol, especially useful if you are programming with SSL libraries:
SSL and TLS: Designing and Building Secure Systems, by Eric Rescorla, 0201615983
OpenSSL project: http://www.openssl.org
ModSSL project: http://www.openssl.org
OpenBSD, a free Unix-server operating system with focus on security: http://www.openbsd.com
Apache reference, by the author of mod_ssl: http://www.apacheref.com
SSLv2 Specification: http://home.netscape.com/eng/security/SSL_2.html
SSLv3 Specification: http://home.netscape.com/eng/ssl3/draft302.txt
SSL related RFCs. RFCs can be obtained from http://www.rfc-editor.org/
Internet X.509 PKI: 2459
Transport Layer Security: 2246
Upgrading to TLS Within HTTP/1.1: 2817
This chapter has introduced you to the SSL protocol and to mod_ssl, which allows Apache to support SSL. You have learned basic installation and configuration of mod_ssl and certificate generation and management. You can access the mod_ssl reference documentation for in-depth syntax explanation and additional configuration information.