Apache and Secure Transactions

One of the most commonly asked questions about Apache is why doesn't it come with SSL support built in. Read this special feature for all the info about Apache and SSL.

Why Use Secure Transactions?

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.

SSL Encryption and Ciphers

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:

CIPHER	BITS	DESCRIPTION
DES	168	These are well-proven, 168-bit, triple-encryption ciphers. Supported by products based on SSLeay such as Stronghold and SafePassage but not by products from Microsoft or Netscape.
IDEA	128	This cipher uses 128-bit keys but it is not commonly found in web browsers or servers. It is possible, but very slow, to use triple-IDEA with 384 bit keys. In the USA and Europe a license from Ascom AG is required to use these ciphers.
RC4 and RC2	128	These ciphers use 128-bit keys, which normally offer a high degree of security. Inside the USA a license from RSA is required to use these ciphers.
Export RC4 and RC2	40	These ciphers use 40-bit keys but are otherwise identical to their equivalent 128-bit versions. Servers and browsers produced by Netscape and Microsoft support these ciphers. Inside the USA a license from RSA is required to use these ciphers.

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.

US Arms Export Restrictions

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".

Key Escrow

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 and ITAR

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. A set of free patches to link Apache with SSL (using SSLeay) is available as Apache-SSL from Ben Laurie in the UK. This is legally useable anywhere in the world except the US for free. 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.

Encryption Patents and RSA

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 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. The main product available is Stronghold (The previous competitor, Sioux, merged with Stronghold in late 1996). Stronghold is jointly developed in the US and the UK so it can also be used with full 128-bit encryption outside the US and Canada.

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 can be used for free.

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

Certificates

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 only approve servers available in binary form, because they require servers to have been audited to ensure that they meet their security requirements. Stronghold has been approved, and they provide the source code for information only. Apache-SSL and any other source-only developments of Apache are not approved, so cannot be issued a Verisign certificate.

Users of Apache-SSL can either get a certificate from another authority, or become a certificating authority themselves (the tools to be this are part of SSLeay).

Summary

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 (currently only Stronghold) and buy a certificate from Verisign, or
2. Download Apache and Apache-SSL patches, compile, pay RSA license for RSA-patented technology, and 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 from Verisign, or
2. Download Apache and Apache-SSL patches, compile, and obtain a certificate from Thawte, or
3. Download Apache and Apache-SSL patches, compile, and sign own certificate