INTRODUCTION TO SSL & HTTPS:

The need for secured information transfer over the internet has become paramount with the growth of commerce transactions over the net. In the early days of the internet, in the days when it was primarily an academic resource, all information was transmitted in 'plain text' - where anyone viewing the data in transit could read it all with simple readily available network tools. With the increasingly sensitive nature of information carried over the internet, [credit cards, personal information, etc.] two major threats 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 in 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 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 is a 'transport layer' - in that other internet protocols may be transported over it in an encrypted form. The most common usage of this is 'HTTP over SSL', and this is what we are concerned with in this chapter. When HTTP is traveling over SSL, this is indicated by a different URL header -https://

e.g.- https://www.mediahostnet.com/secure-order.shtml - this is a 'secured site' - the HTTP connection is traveling over SSL [indicated by the https://] HTTP transports the web page data, SSL encrypts the pages and authenticates that the server [mediahostnet.com] is really operated by MediaHostNet.

To date, no significant weakness have been found in the SSL protocol, and it is a largely accepted standard for secured data transmission. This is partly because of the network of established root authority servers that distribute 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.

To illustrate this, lets take a look at the MediaHostNet server certificate information:

CN = *.mediahostnet.com OU = Secure Services O =MediaHostNet Inc L = Jakarta S = DKI Jakarta C = ID

This reads as "This certificate belongs to MediaHostNet Inc, from Jakarta, DKI Jakarta, Indonesia: it is for use on the servers in the mediahostnet.com domain".

Our server certificates were obtained by Thawte, and they have been digitally signed by Thawte, as Thawte's stamp of approval that MediaHostNet is a real, accountable company [Thawte does this by validating companies in state business registries, etc.], and that when you connect to a MediaHostNet secured server that presents this certificate, you know that it is operated by us, and not by someone else, registering their own certificate in our name.

Of course, this only works if you [or, more accurately, your browser] trusts the certificates issued by Thawte. In the majority of SSL capable browser's today, Thawte is flagged as a trusted issuer and so certificates issued [and signed] by Thawte inherit this trust - if you trust Thawte, you automatically trust all certificates that they sell to companies.

Looking back at the MediaHostNet Web information above though, you will see something we haven't covered yet, though it is the part of the certificate perhaps most important to you as the web designer of your own secured site. The certificate is only valid for servers in the domain 'mediahostnet.com'. If we took this certificate and installed it on a server in another internet domain, to enable SSL on that server, it would not be accepted by the browser.

What does this mean in practicality? Your browser will check the certificate presented to it when you connect to a secured site. If the certificate claims to be from a different domain than the one you are connecting to, it will flag this as a possible security violation [you may be about to send sensitive information to someone that is not who they claim to be!]. Because of this, there are several extra steps to take when setting up secured sites on MediaHostNet.

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].mediahostnet.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 MediaHostNetweb 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 MediaHostNetweb server named 'bandicoot' and your login ID is 'yoursite'.

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

https://bandicoot.mediahostnet.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 mediahostnet.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.mediahostnet.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 MediaHostNet 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 MediaHostNet to arrange this.

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's

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 name="order" 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.

<action="https://bandicoot.mediahostnet.com/~yoursite/cgi-bin/something.cgi">

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.

Back End Security

Although it is beyond the scope of this section of the manual to discuss web site back end security, its important to be aware of it when building SSL enabled sites. SSL is not a panacea for ensuring the privacy of your customers personal information. SSL only addresses the security of the submission of data to your site. The reality of the matter is not that their information will be captured as they submit it, but that it will be captured when you retrieve it yourself from the server, or while it is left waiting on the server for you to retrieve it. SSL can provide reassurance to customers that their information will remain private; but how you process that data once they submit it to your site, is what ensures that it remains private.