go to Reviewsgo to Servicesgo to Registered Usersgo to Resource Centrego to AbleStable: Helpgo to About Us
go to AbleStable: Home Articles
go to Search

go to Exhibitions Centre
  Business: exploring the world of creative professionals
go to Help
go to Resource Centre
go to Library
go to Articles
go to E-Books
go to Glossary
go to Reviews
go to Web Link
Library > Articles > Business > 004

E-mail this web page address to a friend or colleague
Enter their email address below (no record is kept of this action)

Secure Servers
Contributor: Kevin Boone

This article describes the purpose and basic principles of secure Web servers. It is intended for people and organisations who have a sneaking suspicion 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.

The Problem
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 organisational 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.

The solution: a secure web server
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 unauthorised 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 organisation may have an ordinary Web server with the URL:
and a secure server address like this:

Getting a secure server
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..

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

Some technicalities
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.

When communication starts, the server generates two compatible keys. 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. 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. The encrypted data can then safely be sent over the Internet. 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 to decrypt the data. The decrypted data can then be processed by the Web server as normal. 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.

Site and client certificates
When a Web browser is asked to send secured information to your server, it may well ask that your organisation prove it is what it says it is. This is to prevent rogue organisations accepting, say, credit card numbers for nefarious purposes. Your site certificate serves this purpose. The site certificate is a statement of your organisation'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 organisation 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 organisation 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, and ask the user whether to trust it or not. Of course, unless the user knows your organisation 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 organisation 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 organisations 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 drawn out 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 Algorithm') and, given a choice, this is what you should use. However, your server has no control over the encryption techniques 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 organisation'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.

The Summary
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.

Authors background

Kevin Boone is Principal Instructor at Sun Microsystems Ltd. Kevin has been programming professionally since 1989, and as an amateur since 1980. Until recently he specialised in software for control of electronic devices; his software can be found in devices ranging in size from heart pacemakers to an oil platform power plant. Kevin has also become involved in e-commerce development, has taught programming in Java and C++ at undergraduate and postgraduate levels, and has developed software commercially for Windows NT, Solaris and Linux. Kevin's previous position was as Senior Lecturer of `Interactive Multimedia', and was programme director at Middlesex University (United Kingdom).

This article also appears on Kevin's web site at

If you observe inaccuracies or wish to contribute an article or review to be included at AbleStable® visit Feedback.

Copyright Notice
Although our contents are free to browse, copyright resides with the originators of all works accessed at AbleStable®, and unauthorised copying or publication of our site contents is strictly prohibited.

AbleStable © 2002-2010

 All Material: AbleStable © 2002-2010
go to Frequently Asked Questionsgo to Feedbackgo to Press Centrego to Privacy Statement