In this issue

Release: 1.1.1
Beta: None
Bugs in 1.1.1:

• Negotiation module negotiates on proxy requests
• Host: header can override IP addresses in VirtualHosts
• deny and allow cannot handle hostnames starting with numbers (e.g. 123.domain.com)
• ProxyPass can give back a redirected URL rather than munging it into a reference via the proxy
• Digital Unix 4.0 requires -lm library

A multi-threaded version of Apache is under development. It is not yet clear whether this will form part of release 1.2, or wait until 2.0.

Multi-threading is a software term that means that the program does several things at once. In a traditional program, execution continues from one statement to the next in a linear and predictable fashion. In a multi-threaded program, one, two, or more parts of the same program can be executing at the same time. In Apache this means that a single copy of the server can handle multiple requests concurrently.

The current version of Apache does something like this already: it can handle multiple requests by running several copies of the server. However this is not multi-threading because the running programs are different copies, each of which is a different process. In a multi-threaded sever, a single process could be handling a number of requests at the same time. The advantage this gives is two-fold. Firstly, the operating system does not need to keep swapping between different processes, which is slow. Secondly, any static information shared between all the requests (such as the server configuration) can be shared between all the threads running at the same time, instead of being repeated in each process.

Larger sites with high hit rates, or sites using configurations which take up a lot of memory are likely to benefit most from multi-threading.

The following new features will be in the next release:

• Status module improvements
  The status module now records the length of time taken to process each request, and displays it for the most recent. It also handles very large totals better.
• Graceful restarts
  When the server is sent a HUP signal to re-read it's configuration files, it currently cancels all transfers in progress. The next release introduces an new signal, INT, which does the same as HUP but does not kill currently active tranfers.
• Fixes for some systems
  Compilation warnings on IRIX and a problem with closing connections on A/UX are fixed, and a configuration option for HPUX 10 is now available.

The perl module, which runs perl scripts as part of the server, has moved into beta test phase.

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

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

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 free implementation of Apache with SSL (using SSLeay) is available as Apache-SSL from AL Group 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.

The version of SSL used in Netscape uses an encryption method 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). 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 two main products available are StrongHold and Sioux. Note that since Stronghold is developed in the US and incorporates encryption the ITAR rules prevent it being used 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. 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.

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. However now the browser will accept other certificating authorities, but only after presenting a series of dialogue boxes to the user. If the server operator wants their certificates to be accepted transparently by Netscape they will have to get certificates signed by Verisign. Also Microsoft's Internet Explorer version 2 cannot accept any other certificate authorities (this is fixed in IE version 3).

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 both StrongHold and Sioux. Verisign only approve servers available in binary form, because they require servers to have been audited to ensure that they meet their security requirements. Both Sioux and Stronghold have been approved, and 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).

To get a secure server based on Apache, first decide whether you need a certificate signed by Verisign or not (this is determined by whether you mind your users going through the Netscape security wizard when they first connect to your server, or possible using browsers that cannot connect to your site). This may not be a problem in an Intranet environment where you can distribute a browser with your certificate authority already configured. Then:

Inside the US and Canada

Either

1. Buy a Verisign-accredited, RSA licensed server (e.g. Stronghold or Sioux) 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

Outside the US and Canada

Either

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

"The Well Connected Mac: Your Online Guide To Everything Macintosh" site uses Apache rather than a Mac server. The site owner explains why.