Apache Server Survival Guide asg14.htm
- U.S. Law Regarding Exportation and Importation of Cryptography
- The Public Key Partners Patent on RSA (Public-key Cryptography)
- Two versions of Apache-SSL
- So Which Secure Version of Apache Can You Legally Use?
- Installing Apache-SSL
- Installing and Configuring Stronghold
- SSL-Configuration Directives
- Summary
14
Secure Web Servers
With the increase in the use of the Internet as a vehicle for commercial transactions, there are more reasons now than ever to protect sensitive information from reaching unintended eyes. A whole slew of secure client/server applications are appearing every day. Also making an inroad is the digital signature technology, which helps certify that messages you received were indeed sent by the sender. Both of these technologies are rooted in the same core of public-key encryption, which is currently the only feasible way of implementing security over an insecure network such as the Internet. The scope of this technology is to ensure that any form of communication that may contain sensitive information is protected while in transit and to assure the receiver that the message was really sent by the sender.
In the case of Web server technology, this is accomplished with a server that implements encryption at the communication level. The current crop of products implementing security are based on the Secure Socket Layer (SSL) protocol specification developed by Netscape Communications for use with their server and browser products. For details on the SSL protocol, visit http://home.netscape.com/newsref/std.
Of the many reasons to use a secure HTTP server, the two most important ones are information privacy and data integrity. If you put sensitive information on your server, you may want to protect your information from being captured or modified by unscrupulous people while in transit. The SSL technology ensures this.
Two variants of the Apache server, Apache-SSL and Stronghold (Apache-SSL-US), are available. They both provide 128-bit symmetric-key encryption that is fully compatible with the Netscape's SSL protocol. These servers are fully compatible with browsers that understand this protocol. Currently, this includes browser offerings from Netscape, Microsoft, and others.
Because of the technology involved, which flavor of the Apache software you'll be able to legally use will depend on where you live. There are two issues that affect most products that implement encryption technology, including SSL technologies:
- The U.S. law regarding exportation of encryption technology (cryptography).
- The Public Key Partners patent on Rivest-Shamir-Adleman (RSA) public-key cryptography
U.S. Law Regarding Exportation and Importation of Cryptography
Exportation of cryptographic technology is highly restricted and regulated by the U.S. State Department under the International Trade in Arms Regulation. This regulation classifies cryptographic devices, including software, as munitions (as in armament and ammunition).
Ultimately, any export license request for cryptographic technology is passed down for approval to the National Security Agency (NSA). The NSA has jurisdiction over the exportation of cryptographic technology issues because its mandate as an agency is to listen and decode all foreign communications of interest to the security of the United States. Encryption technology can obviously create problems for this agency when they are trying to go about their business. Naturally, from their point of view, they need a policy to eliminate sources of grief where they can. This means putting restrictions on the exportation of U.S. products that implement encryption technology.
In other words, the intention of the law is to reduce or prevent the possibility of some subversive country utilizing a U.S.-developed encryption technology that is too strong and time consuming for the NSA to break. This type of technology could make it difficult to decode information that may adversely affect the security of the United States.
The problem with this law is complex. The NSA will approve (and has done so in the past) exportation of cryptographic technologies that it is able to crack or have some sort of backdoor available for this purpose. Rumor has it that they have all the toys and best minds in the business dedicated to this purpose alone.
From a technology provider's point of view, the problem is that the intention of any cryptographic technology is to make it very difficult to read encrypted data. Even if it was feasible to crack through brute force, the resources needed for this task would approach government budgets. Even then it should take some time to crack. The result is that many encryption products don't make a debut outside of the United States because an international version may have to compromise its security to get the export license or the hassles involved in exporting it are too great. Developers of encryption technology are angry because this policy limits their ability to reach a world market. In a world-information system such as the Internet, it becomes very difficult to police and enforce this type of law.
The Public Key Partners Patent on RSA (Public-key Cryptography)
The second issue regarding use of Apache-SSL, Apache-SSL-US, and other encryption technologies has to do with the patent on public key encryption systems.
The traditional problem with encryption is that in order for the recipient to decode encrypted material, she would need to know the key used by the sender to encrypt it; the sender uses a key (like a password) to encrypt a message. The receiver must use the same key to decrypt it. Since the keys need to be the same, for both encryption and decryption, the problem with this technology (secret-key cryptography) lies in the transmission of the key. Exchange of the key information needs to transpire without anyone else learning it.
This makes the data vulnerable because even though the encrypted data could be easily and securely transmitted over open communication lines, the key portion could not. If anyone else got a hold of your key, be it by looking at your e-mail or listening in on your phone lines, they could decode the information. The more times you transmit and reuse the key, the more vulnerable the key becomes.
To eliminate the problem of key transmission, public-key cryptography was developed. This system uses two keys: a private key and a public key. The private key, as its name suggests, is kept private by its owner. This key is used for decoding information, it is never sent to anyone (see the following note). The public key on the other hand can be freely disseminated and can be publicly posted because it can only be used to encrypt messages destined to its owner.
When you wish to send a message to someone, you would use their public key to encrypt your message. Only the recipient, with his private key, would be able to decipher that message.
RSA, the algorithm that implements public-key encryption, is patented under U.S. Patent 4,405,829, which was issued on August 20, 1983 (this patent expires in the year 2000). The patent is held by Public Key Partners (PKP) of Sunnyvale, California. RSA is licensed under a royalty-based licensing policy, which works as follows:
- If you develop a product and license the RSA technology, any one who purchases the product has a right to use the RSA technology within the product you developed. The U.S. government can use RSA without a license because it was invented in 1977 by Ron Rivest, Adi Shamir, and Leonard Adleman at Massachusetts Institute of Technology with partial government funding.
- PKP allows free noncommercial use of RSA with written permission, for personal, educational, and intellectual reasons. RSA Laboratories has even made available a collection of cryptographic routines in source form that include the RSA algorithm, which can be used, improved, and redistributed noncommercially.
- RSA is not patented outside of North America.
Two versions of Apache-SSL
As mentioned earlier, there are currently two versions of the Apache server implement SSL encryption technology. The SSL technology uses a public-key encryption system to encode the transmission.
Apache-SSL
Apache-SSL is a set of patches developed in the United Kingdom by Ben Laurie ( ben@algroup.co.uk) that incorporate SSL functionality to Apache. In addition to his patches available from http://www.algroup.co.uk/Apache-SSL, you'll need to obtain the sources to Apache and the SSLeay library to build Apache-SSL. The product is free for both commercial and noncommercial use. It supports 128-bit encryption, client authentication, and all the other features of Apache.
Apache-SSL uses the SSLeay, an implementation of the Netscape's SSL, the software encryption protocol behind Netscape's products. SSLeay was developed by Eric Young as a library that can provide SSL security to any TCP application. This implementation was programmed using only the publicly available protocols and supports DES, RSA, RC4, and IDEA encryption algorithms. You can obtain the SSLeay library from http://www.psy.uq.oz.au/~ftp/Crypto/. However, its use is only legal outside of the United States and Canada because of the patent issues with RSA and RC4.
Stronghold (Apache-SSL-US)
Stronghold, developed by Community ConneXion ( http://www.us.apache-ssl.com), also uses the SSLeay SSL implementation. However, it licenses the RSAREF libraries from RSA Data Security Inc., which provide SSL configuration documentation. Stronghold also provides Certificate of Authority tools. Stronghold is free for noncommercial use. Commercial users must pay a licensing fee of $495.00. Customers upgrading from a competing SSL Web server from Netscape have a special discount price of $295.00.
Some of the technical differences between Apache-SSL and Stronghold are the licensing of the RSA technology, availability of the CA, additional software tools, and availability of support. Apache-SSL's SSL implementation doesn't license the RSA technology; Stronghold does. Because Stronghold licenses the RSAREF libraries, it is an approved product. So VeriSign, an offshoot of RSA, will issue a Certificate Authority (CA) for Stronghold, although in the future they may also do it for Apache-SSL. Stronghold also provides additional tools useful for creating new certificates and manage existing ones. Lastly and most importantly, you can think of Stronghold as shrink-wrap. Commercial licenses of Stronghold (paid versions) are entitled for technical support. The Stronghold software is also much easier to install because it comes as a complete package, not just as a set of patches. Stronghold is currently compatible with 16 platforms including SunOS, Sparc, Solaris, X86 Solaris, AIX, BSDI, Linux (ELF & a.out), FreeBSD, IRIX, UnixWare, Ultrix, DG/UX, HP-UX, OSF/1, and NEXTSTEP.
So Which Secure Version of Apache Can You Legally Use?
As I mentioned earlier, which version of Apache you are allowed to use depends on where you live. If you live in the United States or Canada, you must use Stronghold (Apache-SSL-US). This version of Apache uses the same SSLeay libraries as Apache-SSL, but it licenses the RSA libraries. By licensing the RSA libraries, Community ConneXions eliminated the patent issues associated with the RSA public-key encryption implemented by the SSLeay libraries.
To add another twist, by legalizing Stronghold in the United States by incorporating the RSA libraries, exportation of Stronghold now falls under the regulations of the U.S. State Department under the International Trade in Arms Regulation, making its use only possible in the United States and Canada. Stronghold is not licensed to be exported outside of the United States under the current law.
In you live outside of the United States and Canada, then the United States patent on the public-key cryptographic system doesn't apply to you. Apache-SSL, with its own implementation of the RSA algorithm that doesn't incorporate any code from the RSAREF toolkit, can be used legally anywhere but in the United States and Canada. In those two countries it violates U.S. patent law. To be certain, you may also want to become aware of other local restrictions and regulations regarding the use of cryptographic technology before you implement a server that uses this technology.
Installing Apache-SSL
For users outside of the U.S. and Canada, Apache-SSL is distributed in patch form (note the version of the patches). The patches can be obtained from http://www.algroup.co.uk/Apache-SSL. You'll also need the SSLeay libraries, available in source form from http://www.psy.uq.oz.au/~ftp/Crypto, and pick the latest version. You'll also need to verify that you have a matching version of the Apache server from http://www.apache.org.
As of this writing, the patches were for Apache version 1.1.1. The files you'll need are
Apache source: apache_1.1.1.tar.gz
SSLeay library: SSLeay-0.6.3.tar.gz
SSL patches: apache_1.1.1+1.3.ssl.tar.gz
You should move all the distribution files to a directory. You can use Apache Server as a temporary holder. Here's how the patches are unpacked and applied. Note that apache_1.1.1+1.3.ssl.tar.gz is unpacked in the Apache 1.1.1 distribution directory. Doing this will install additional files for the patch program as well as create some files unique to the SSL distribution. The SSL patches are applied with the patch utility. If your system does not have patch, I have included a copy on the CD-ROM. Otherwise, you can download the latest version from ftp://prep.ai.mit.edu/systems/gnu/patch-2.1.tar.gz.
Before compiling SSLeay, read the INSTALL document. Then edit Makefile.ssl to match your system configuration. If your perl binary is in /usr/local/bin/perl and you don't mind installing the libraries and other programs in /usr/local/ssl, all you may need to do is set up your compiler options.. When you are done, run the Configure program. Here's a listing of the commands you'll need to apply:
