Introduction

The need for secure information transfer over the internet has become paramount with the growth of commerce transactions over the net. In the early days of the internet, when it was primarily an academic resource, all information was transmitted in 'plain text' - anyone viewing the data in transit could read it with simple, readily available network tools. Due to the increasingly sensitive nature of information carried over the internet, [credit card numbers, personal information, passwords, etc.] two major threats to the the integrity and privacy of this data have arisen:

• Man in the Middle - It is a fact of TCP/IP [internet] networks, that all data passing through a machine, regardless of its final destination, may be viewed and captured. To illustrate this: Picture a standard input form on a web page, asking for credit information. After pressing submit, this information travels through several computers [routers] to its final destination at the web server. A person with sufficient access to one of the computers along this path [or a machine on the same network as one of these computers] may read the data as it passes through, without indication to the other parties that such interception is taking place. If the data in question is being transmitted 'in the clear' [as human readable text] then no further effort is required on their part, they have a carbon copy of the submitted information.
  
  
• Host Impersonation - The other major threat to information privacy is where the host you are submitting data to is not who you believe them to be. A server has been set up, and the address is question has been redirected through technical trickery or otherwise, to an un-trusted third party. E.G. you connect to Party A's server, to make an order; yet unknown to you, Party B has set up an identical server, and had the addresses for A's servers redirected to their server, to capture your information as you submit information to what you believe is trusted party A's server.

SSL Technology

SSL is 'Secure Sockets Layer' - a technology developed several years ago to address these two major problems with transferring sensitive data over the internet. To the end user, such as yourself, SSL provides two chief features to address the weaknesses described above:

• Encryption - That is, the scrambling of data in transity between client and server; rendering all intercepted data unintelligible to any third party [without the application of unfeasible amounts of mathematical processing]. SSL offers varying levels of encryption strength, from '40-bit' [US export Grade] to 128-bit [US Domestic Grade]. Essentially, the more bits, the stronger the encryption.
  
  
• Authentication - This is the requirement of a truly secure connection between client and server; that both parties must have assurance of the identity of the other party. There are ways to mathematically prove the identity of the remote party of a secure connection.

SSL Certificates

SSL certificates (and their relatives - X509 certificates, server certificates, digital certificates and digital signatures) are mathematically generated files, that when fed to some complex mathematical algorithms, can act as both a digital 'key' and 'signature' to a web server. SSL certificates use public key encryption. You may have encountered single-key systems before. This is where both parties have the same password/key, and the message send between them and locked and unlocked with the same key. This arrangement has many problems, and so today we use public-key systems; which have two keys : a public key and a private key, and a side effect of the two keys, called digital signatures.

• Public Key - The 'locking' key .It is sent out to everyone who you want to be able to encrypt data to be sent to you. Once data has been encrypted with your public key, it can only be decrypted by your private key.
  
  
• Private Key - This is the key that only you hold, the 'unlocking' key, and the only thing that can unlock data that has been encrypted with your public key. It should be noted that it is mathematically impossible for someone with your public key, to replicate your private key.
  
  
• Signatures - If you have someone's public key, and they have yours; then it becomes possible, when you encrypt data to them with their public key, so 'sign' the data with the 'fingerprint' of your private key. In this manner, when they receive the data you have encrypted to them, they can check whether the signature on the data matches the public key they have for you. If they have previously ensured that the public key they have for you, is indeed your key, then they have a mathematical proof that the encrypted data you send to them, could only have come from you.

So now two questions remain; where do digital certificates come from, and how do people match up public keys to an individuals true identity? The answer to both is the Root Certificate Authority. Root authorities can be local to a business, or they can be companies selling their services to the public. Two well known Root Certificate Authorities are VERISIGN and THAWTE, two companies in the business of providing certificate services. They also act as 'root trust authorities'. What this means in practice, is that the server certificates sold by these companies are guaranteed [through legal and technical means] to belong to the parties the certificate claims to belong to.

Accessing Pages Through SSL

So you want to make some of your site content accessible over SSL, and enable your visitors to submit information to your site over SSL as well. If your requirements are fairly modest, then very little work is required.

To access any page on your site securely, you must access it through a different URL: The format of which is:

https://[hostname].leveltenhosting.com/~[username]/[regular path to file]

Lets break this down:

• https:// - To specify that an SSL connection should be made, http:// becomes https://
• hostname - This is the name of the Level Ten Hosting server you are hosted from.
• ~[username] - Your main login ID goes here.
• [regular path to file] - This is the path to the file you wish to access, just as you would use in the regular http:// URL.

Here are some practical examples:

You wish to access the file http://www.yoursite.com/doug/stats.html in a secure connection. Your site is hosted from the Level Ten Hosting server named 'bandicoot' and your login ID is 'yoursite'.

http://www.yoursite.com/doug/stats.html becomes:

https://bandicoot.leveltenhosting.com/~yoursite/doug/stats.html

It's important to note that these two addresses point to the same file on the same server - you do not have to copy files you wish to access through SSL to a different location, you only address them differently in the browser.

Why cant you use https://www.yoursite.com ? The answer lies above in the information about certificates - the SSL certificates on our servers say they belong to leveltenhosting.com; when a browser connects to https://www.yoursite.com, the web server will present them with a certificate that claims it belongs to https://www.leveltenhosting.com - the browser will halt at this point and refuse to connect. This is why you modify the URL you use, so that it addresses the server you are hosted from, within the Level Ten Hosting domain.

Should you wish to be able to use https://www.yoursite.com you will need to obtain your own server certificate from a Certificate Authority service. Please contact Level Ten Hosting to arrange this.

Using SSL Effectively

Use SSL only where necessary
The first task when incorporating SSL into a web site, is to consider carefully where SSL should be used. SSL is computationally intensive - pages load slowly over SSL, and place greater load on the web server. A product order form would be a very good place to use SSL, however, file downloads would be a waste of resources at best.

Submitting Data through SSL to CGI and PHP applications
Sending data from a HTML form page, over a secured connection to a CGI application running on the web server [e.g. the ubiquitous order processing application] is likely to be your main usage of SSL, so we give it closer coverage here.

The HTML code for a form page begins with a tag that looks like this:

<form action="http://yoursite.com/cgi-bin/something.cgi" method="POST">

It is the action part we are interested in here. This is the URL that the contents of the form will be sent to when the submit button is pressed. This is where we should use the https:// URL, so that the data is submitted over the secured channel. e.g.

<form action="https://bandicoot. leveltenhosting.com/~yoursite/cgi-bin/something.cgi" method="POST">

Note here that it is not necessary to load the order page itself over https:// [who would be interested in a blank order form?] only to specify that the data be submitted ['form action'] over SSL.

Since most CGI's respond to a successful operation by returning HTML data [i.e. an order confirmation] this information will be returned down the same https:// channel that was used to submit the data.