|
|
Library
> Articles >
Business
> 004
|
|
|
|
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:
http://www.your-name.com/
and a secure server address like this:
https://www.your-name.com
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 www.kevinboone.co.uk.
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 |
|
|
|
