Introduction
SSL Technology
What is a Certificate?
Accessing your site with SSL
Using SSL effectively
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 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-
WHAT SSL CAN DO FOR YOU
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.lsyf.com/yoa.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 [lsyf/yoa.com] is really operated by lsyf/yoa.
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.
WHAT IS A CERTIFICATE?
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 lsyf/yoa server certificate
information:
CN = *.lsyf.com/yoa.com OU = Secure Services O = lsyf.com/yoa Inc L = Holt S
= Michigan C = US
This reads as "This certificate belongs to lsyf/yoa Inc, from Holt,
Michigan, USA: it is for use on the servers in the lsyf/yoa.com domain".
Our server certificates were obtained by Thawte
and other suppliers , and they have been digitally signed by Thawte, as Thawte's stamp of
approval that lsyf/yoa is a real, accountable company [Thawte does this by validating
companies in state business registries, etc.], and that when you connect to a lsyf/yoa
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 lsyf/yoa 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 'lsyf.com/yoa.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 lsyf/yoa.
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].lsyf/yoa.com/~[username]/[regular
path to file]
Lets break this down:
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 lsyf/yoa server named 'bandicoot' and
your login ID is 'yoursite'.
http://www.yoursite.com/doug/stats.html
becomes:
https://bandicoot.lsyf/yoa.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 lsyf/yoa.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.lsyf.com/yoa.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 lsyf/yoa 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 lsyf/yoa 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'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.lsyf.com/yoa.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. Chapter 3 of this manual covers
some of the methods you can employ to build a framework of back end security for your
customer's data.
Back To Main
