Feature: Apache and Secure Transactions

We explain what SSL is, why Apache does not have it built in, and why it is such a complex issue. We examine the restrictive US government rules and commercial interests that together restrict what can be imported and exported from the US and Canada.

First published in Apache Week issue 24 (19th July 1996). Last updated 1st September 1998.

Most of the information passed across the Internet is not particularly sensitive. In fact, most if it is specifically designed to be as widely read as possible. But some information is sensitive. For example, when ordering from a site via credit card, the credit card number is transmitted across the Internet from the browser to the server. In theory, a third party could intercept this information at some point on the network between the browser and the server. To prevent this, some form of encryption can be used so that even if someone intercepts the data they cannot decode it back to the original credit card number (or what ever else it was that was encrypted). Obviously both the browser and the server need to use the same encryption method. The most widely implemented encryption system for the Web at present is SSL.

SSL stands for Secure Socket Layer, a protocol developed by Netscape for secure transactions across the Web. It uses a form of public key encryption, where the information can be encoded by the browser using a publicly available public key, but can only be decoded by someone who knows the corresponding private key.

Any product can incorporate SSL technology without paying any royalties. Extending Apache to handle SSL is a programming job, made relatively easy by the availability of a free SSL implementation, called SSLeay. However, the US government effectively prevents Apache from doing this.

Although it is the SSL standard that defines how the encryption is applied to Web transactions, the actual encryption itself is performed by a number of cipher algorithms. When an SSL browser and SSL server first communicate they mutually pick a cipher algorithm that both support. Some commonly used ciphers are listed in this table:

An interactive tool from Netcraft is available that can query any secure Web site and show which ciphers it supports.

Experts agree that 40 bit encryption does not provide an adequate level of safety and there have been several publicised hacks (See C|Net story).

A panel of cryptographic experts including Whitfield Diffie, the inventor of public key cryptography, issued a report in January 1996 that said a minimum of 75 bits was necessary for "adequate protection against the most serious threats" and 90 bits was necessary to thwart advances in hacking techniques for the next 20 years.

The US Government imposes export restrictions on arms, in a set of rules called ITAR (International Traffic in Arms Regulations). Amongst the restricted arms is "strong" encryption software. (See the EFF archive on ITAR). Software that implements SSL in the US cannot be exported because of these rules (actually, it can be exported to Canada, but no further).

SSL enabled software can be exported outside of the US if the software can only encrypt using a maximum of a 40 bit key. Commercial server vendors in the US such as Netscape and Microsoft export secure servers using this weekened 40 bit encryption. Recent legislation allows for registered companies to export software that uses 56 bit keys, but only if they allow the US government to access the data under certain circumstances. This is normally done by allowing a third-party to store or recover the keys - a system referred to as "key escrow". Higher levels of encryption can also be exported to approved financial institutions (primarily banks).

The US and other governments are worried that they cannot access information once it has been encrypted. They would like to be able to decrypt all encrypted data. For some time, the US government has only supported encryption schemes which would allow them to decrypt the encrypted data if necessary, such as the "Clipper" chip. In normal (secure) encryption, the only people that can decrypt the data are the sender and recipient, who between them have the necessary keys. But in key escrow schemes a third-party will also have the ability to decrypt the data (this third-party may be the developer of the encryption product, the US government, or some other "trusted" organisation). Key escrow is also referred to as key storage or key recovery.

From January 1997 the US government has been allowing the export of encryption technology up to 56 bits, but only if the exporter agrees to key escrow. This would allow the US government to decrypt any data encrypted with these exported 56 bit systems. Companies which wish to export 56 bit encryption products need to be specially licensed by the US government.

Apache is developed by an international team of individuals, using a server in the US. The ITAR rules mean that if the Apache server included SSL it could not be exported outside the US. This would prevent the non-US developers from continuing to work on it, and would stop anyone outside the US from using Apache. A solution to this problem adopted by some free software developers is to run a parallel development effort outside the US. The US development would not contain any SSL or encryption technology, while the non-US version would. The main problem with this arrangement is ensuring the parallel development of the two versions, and it would also require a non-US site to host the development.

The problems with the export restrictions of ITAR are not limited to Apache or other free software. Many US corporations are concerned that their competitors in other countries are able to make and sell encryption-enhanced products which they are forbidden to export. (See C|Net report).

In the meantime, while Apache remains an international software development based on a server in the US, it cannot incorporate SSL. There are patches to link Apache with SSL (using SSLeay), such as mod_ssl and Apache-SSL. These are legally useable for free anywhere in the world, except for the US. The problem with using this version in the US is not the export regulations (which only apply to export, not import), but rather because of the sometimes confusing issues of encryption patents and certificate authorities.

Commercial servers such as Netscape base their SSL implementations on ciphers that are developed and patented by RSA Data Security in the US. Use of this technology normally requires a license fee inside the US. If Apache-SSL or mod_ssl is imported into the US, then any user would have to arrange to pay the appropriate license for the patented encryption methods which are part of SSLeay (although non-commercial users can use a license-free implementation of RSA, called RSAref). It may be difficult for an individual to license RSA. The alternative to paying the RSA license individually is to buy a commercial version of Apache with SSL for which RSA has already been licensed by the developer. Examples of such products are the Apache module Raven and the web server Stronghold. Stronghold is developed outside the US so it can also be used with full 128-bit encryption outside the US and Canada. Raven is not available outside the US and Canada with 128-bit security.

Outside the US, no license fee is required for the use of the RSA methods because they are only patented inside the US and SSLeay uses an independant implementation of the cipher algorithms. This means that outside the US Apache-SSL and mod_ssl can be used for free.

Having got a server, the final thing required before it can be used for secure transactions is a certificate.

A server certificate is a piece of digitally-encrypted information that lets the browser know what organisation it is accessing. To prevent people just making up certificates and pretending to be official organisations, certificates can be obtained from a certificate authority, who use their position as a third-party to verify that the organisation using the certificate is who they say they are. Probably the best know authority is Verisign in the US. In fact, early versions of Netscape Navigator (version 1) would only accept certificates from Verisign.

Other certificate authorities can be used but unless they are recognised by the browser manufacturers they will either be rejected when a user tries to connect or the user will be given a long sequence of warning screens. An example of this is Thawte, whose certificates are accepted by Navigator version 3 and Internet Explorer version 3.01 but not previous versions of either browser.

If the server operator wants their certificates to be accepted transparently by all versions of Netscape and Internet Explorer they will have to get certificates signed by Verisign.

To get a certificate from Verisign the server in use must be approved. Most commercial secure servers will have been submitted for approval by their developer, and certificates are available for Stronghold. Verisign will also issue certificates for web servers using the free SSLeay libraries, such as Apache-SSL.

To get a secure server based on Apache, first decide on your certificate authority. If you want every browser to connect seamlessly you'll need a certificate from Verisign. If you don't mind that older browsers will have to go though the Netscape security wizard or be unable to connect you could use Thawte. If you are in an Intranet environment you can distribute browsers with your certificate authority already configured so you may wish to issue your own certificate. Then:

Inside the US and Canada

Either

1. Buy a Verisign-accredited, RSA licensed server (such as Stronghold) or add Raven to Apache, and buy a certificate, or
2. Download Apache and Apache-SSL or mod_ssl patches, compile, pay RSA license for RSA-patented technology, and buy a certificate or sign own certificate (however RSA may not license RSA to individuals)

Outside the US and Canada

Either

1. Buy a Verisign-accredited server from a non-US vendor (e.g. Stronghold) and buy a certificate, or
2. Download Apache and Apache-SSL or mod_ssl patches, compile, and buy a certificate or sign own certificate