The K-Zone: A ten-minute guide to setting up a secure Web site

This article describes the purpose and basic principles of secure Web servers. It is intended for people and organizations who have a sneaking suspiscion that they ought to be using one, but aren't sure why or what to do about it. The article describes what a secure Web server can do and -- perhaps more importantly -- what it can't.

Communication between Web browsers and Web servers takes place, in general, over the Internet. Normally the information that is sent between the server and the browser is perfectly understandable to anyone who happens to be listening in. This situation is analogous to an ordinary telephone conversation: if someone is able to get access to the electrical connections between the two telephones, at any point, that person can eavesdrop, and even put spurious information into the conversation.

Eavesdropping Internet communications is not technically trivial, but neither is it rocket science. But, on the whole, people have less trust in the security of Internet communications than they should. It has been suggested that over 50% of people believe that sending your credit card number over the Internet has the same level of security as shouting it from the rooftops. This isn't true: it's about the same level of security as a making a telephone call from an organizational switchboard. A small number of people will be able to listen in quite easily; a large number of people will be able to listen in if they really want to badly enough and have the technical expertise, and the overwhelming majority of people will have neither the access nor the expertise.
If you intend to provide on-line shopping services, you may expect your customers to send you their credit card numbers over the Internet. You owe it to your customers to take reasonable precautions to keep this information -- and other confidential data -- secure, and potential customers are more likely to trust your business if they can see that you take this security seriously.

While most potential customers won't know what a `secure server' is, they will generally know that it's a good thing. A secure Web server overcomes the problem of unauthorized eavesdropping by encrypting (`scrambling') all the data that flows between the client and the server, in either direction. When the browser begins a connection to the secure server, the browser and the server exchange key (`password') information; if they can agree on the types of key and encryption technique to be used, then communication can begin. This process does not prevent people from eavesdropping on the communication but, even it they do, what they see won't make any sense.

Data sent from the server to browser is encrypted (`scrambled') by the server, put onto the Internet, then decrypted (`unscrambled') by the browser. Information sent from the browser to the server is encrypted by the browser, then decrypted by the server.
The browser signals its intention to communicate with a secure server by using a Web URL that starts with `https:' rather than the usual `http:'. So your organization may have an ordinary Web server with the URL:

http://your_name.com/

and a secure server address like this:

https://your_name.com

A secure Web server is a combination of hardware and software, just like an ordinary Web server. Any computer that is able to run an ordinary Web server can, in principle, run a secure server. Indeed, the same computer may run both secure and insecure servers at the same time. Some server software can handle both secure and insecure communications. For example, the Apache Web server has an add-on module that allows it to handle secure communications (there is also a version of Apache called `apache_ssl' that has this support built in). Apache is a free product; there is no charge for either the secure or the insecure version, even for commercial use.
There are a number of commercial SSL-based Web server products; for a business, buying a commercial server may have a certain appeal, because you can reasonably expect a level of technical support. However, you won't get a better product; the Apache server is still the best available, and it's free. In the USA there is a slight complication: at present US organizations have to pay a licence fee for use of the RSA encryption algorithm, even when it is built into the server software; it can therefore work out cheaper to buy a commercial product that has this licence cost included. When the RSA patent expires (September 2000) the USA will be in the same position as the rest of the World.
Setting up a secure server is slightly more complicated than an insecure one, because it needs to be provided with a site certificate (see below).

The technique that is normally used for secure Web server/browser communication is called SSL. SSL stands for `secure socket layer'. A `socket' is the name for the logical connection between the client and the server, and implies that the encryption takes place at a very low level of communication. This means that there don't have to be different methods for encrypting text, images, sounds, Java applets, etc., all communication between the client and the server is encrypted the same way.
A classic problem in encryption is that of communicating the key (`password') from one end of the communication link to the other. For encryption to work, the sender and the receiver must be using compatible keys. However, in Web communication there is no safe way to send the key: if there was, we wouldn't need encryption. The solution is to use what is known as asymmetric encryption. In this technique, the keys used for encryption and decryption are different but compatible. The process is illustrated in the diagram below, for the case where data is being sent from the client to the browser (your credit card number, perhaps).

When communication starts, the server generates two compatible keys (step 1 in the diagram). The `public' key can only be used for encryption; it can't decrypt. So this key can be safely sent over the Internet to the browser (step 2). If someone intercepts this key, it will not be very useful as it can only be used to encrypt. The browser uses the public key to encrypt the data to be sent to the server (step 3). The encrypted data can then safely be sent over the Internet (step 4). If someone listens to this data, it won't make any sense because the `private' key is needed to decrypt it. The server retains the private key and uses it (step 5) to decrypt the data. The decrypted data can then be processed by the Web server as normal (step 6).
This whole process is carried out in reverse when data is sent from the server to the client.
The public key/private key scheme is the foundation for all modern secure communications techniques, and is very robust. It is not, however, infallible. There are a number of well-known techniques (see any communications textbook) by which a person with sufficient technical expertise and access to the network at the hardware level can attempt to break the security. In practice, SSL -- when correctly configured -- is perfectly adequate for all commercial purposes.

When a Web browser is asked to send secured information to your server, it may well ask that your organization prove it is what it says it is. This is to prevent rogue organizations accepting, say, credit card numbers for nefarious purposes. Your site certificate serves this purpose. The site certificate is a statement of your organization's name, location and Internet domain. Because anyone can generate a site certificate, a Web browser won't automatically trust it. It will expect it to be signed by an organization that it trusts. This signing is the addition of some numeric information that is difficult (or impossible) to forge, and can reliably be traced back to the signing agency. Most Web browsers are preconfigured to trust a number of certification authorities, the best-know of which are Thawte and VeriSign. However, they will also accept a certificate that has be signed by an organization whose own certificate has been signed by a trusted agency. In other words, there is a `chain' of trust extending from your site certificate to an agency that the Web browser trusts. Some Web browsers limit the length of this chain, to reduce the potential for fraud.
If your site certificate can't be verified this way, the browser won't automatically reject the connection. Usually it will ask the user what to do. The browser will usually pop up the information contained in the certificate (see below), and ask the user whether to trust it or not. Of course, unless the user knows your organization directly, he or she won't trust it, and will click the `No!' button, and that will be a potential customer lost. In other words, it makes sense to pay the modest fee to have your site certificate signed by a trusted agency.

Certificates work both ways: as a server operator you have the right to ask the browser to present its credentials as well. You might want to do this if you are using a Web server to distribute sensitive commercial information between different parts of your organization. As the server can't stop and ask someone whether to accept a dubious certificate or not, the server manager must provide quite detailed and authoritative information about which signing agencies to trust. In a commercial environment, you yourself may be the signing agency for your server. The server can then be configured to trust only those browsers whose certificates have been signed by yourself. This works quite well in small-to-medium sized organizations. Note that this procedure, although fiddly to set up, is far superior to password-protecting certain areas of your server. The password scheme prevents casual hackers from nosing around your private server, but it does not force the data to be encrypted, and therefore does not reduce the risk of eavesdropping.
Installing site certificates is generally quite a fiddly process. It involves generation of a `certificate signing request', despatch to a signing agency, and then installation of the signed certificate. Your Web server should provide full instructions on how to do this; the problem is that the authors of these instructions tend to forget that the readers generally don't have Master's degrees in cryptography.

It is very important to understand that a secure Web server uses encryption for communication of data between the Web server and a browser and nothing else. It does not encrypt the data stored on its own hard disk, or implement any other method to secure the computer itself, nor does it encrypt for other communication software. The security of your server may be vulnerable to attack in a number of different ways; the use of SSL makes absolutely no difference to this.
      Using SSL on your Web server does not mean it will be used for other communications software. Suppose, for example, that you are using on-line shopping software that records customers' credit card numbers on the server along with their orders. How will you get that information from the Web server to your desktop PC? If you use FTP or Telnet to connect to the server, you could be in trouble. Neither of these procedures uses encryption by default, so you will be exposing information to the Internet and negating any benefit of using SSL in the first place. You can get secure versions of FTP and Telnet that use SSL themselves, or you may be able to have the ordering software e-mail orders to you in encrypted format (using PGP for example). In any event, you can't assume that just because you're using a secure server, you will solve all your security problems in one go.
      A secure server won't automatically restrict access to any part of your Web server's content. It merely ensures that this access uses encryption. If you want to restrict access, you need to use other techniques in conjuction with SSL security; most Web servers allow username/password restriction, and you can also control access by means of client certificates.
      Finally, remember that SSL does not specify the type of encryption to be used. Currently SSL understands nine different encryption techniques, of varying robustness. The strongest (probably) is IDEA (`International Data Encryption Algorith') and, given a choice, this is what you should use. However, your server has no control over the encryption technqiues that a browser can support. Suppose for example that a browser connects to your server and requests the use of a a `weak' encryption technique. By default the server will accept that this is the browser's choice, and use the weak algorithm. If it is likely to be your organization's critical data that the browser is sending, then you should probably configure your server to reject such requests. In practice, most browsers now support fairly strong encryption techniques, so it isn't usually a problem.

A secure Web server prevents eavesdropping on communication between a Web browser and a Web server, and gives some measure of confidence in the identities of the parties at each end of the communication link. A secure server is relatively easy to set up, and needs little maintenance once configured. A secure server will not -- by itself -- prevent attacks on the security of your system that aren't related to Web access.
©1994-2006 Kevin Boone, all rights reserved