[ glossary ]


(SSL = secure socket layer protocol)

In many web applications the use of the secure socket layer (SSL) protocol is required. If you are a frequent user of e-commerce sites, you are undoubtedly familiar with the concept - basically, the URL of the page will start with https:// (as opposed to the "normal" http://) and the browser will encrypt all information sent to the site.

But not only! SSL also plays an important role as a mechanism for authenticating your data's destination. When you enter your credit card number while buying books, for example, you want to make sure not only that the information is encrypted, but also that you are submitting your card to a real bookstore (let's say, Amazon.com) and not to some illicit web site which imitates it.

Thus, the SSL protocol helps accomplish two different and equally important tasks:
  1. Encryption. Making sure that information you submit is encrypted in a way that makes it impossible to be intercepted by a third party.
  2. Authentication. Making sure that the target destination site for your (encrypted) information is really what it says it is.
SSL is based on the notions of public-key cryptography and central certificate authority (CA) - the latter is for managing certificates.

So, how does one get started with creating a secure web site?

First of all, you will need to create a web site and put web site online. We strongly recommend using a dedicated server for any type of secure hosting. The reason being that it is much more difficult to break into a separate computer than it is to compromise one of the accounts on a shared server. (Remember - if somebody gets to data directly on your server the fact that you used a secure server to collect the data does not help you at all.)

The second step is to acquire an SSL certificate. There are two options here:

  1. If you think that only a few people whom you already know will access your SSL-enabled web site, then the easiest (and the cheapest) way to create a certificate is to generate it yourself. However, the problem is that you are NOT a recognized certificate authority. While self-signed certificates are fine for small private sites (e.g. intranets or extranets), they are not appropriate for the general public. Simply speaking, your visitors will get security warnings (a result of the fact that you're an unknown certificate authority) and will have the option of either importing or rejecting the certificate.
  2. So, for public web sites, you will need a real SSL certificate. In order to obtain it, you generate a certificate signing request (CSR) and submit it to the certificate authority of your choice. The CA should verify your identity (usually by calling) and issue a digitally signed certificate, which you can start using on your web server.

    This way, the CA guarantees that your certificate really belongs to you. Since the CA will be automatically recognized by all web browsers, your site's visitors will not get any security warning while transmitting secure data on your site.

The option of having a CA-signed certificate does not come free. In fact, it often costs hundreds of dollars per year. One such CA is Verisign www.verisign.com, which, as of August 2003, offered a CA service for the price of $349/year. (There is a way to get a 10% discount using a special offer from RedHat.)

Now, onto the ever-important "technical details".
  • The creation of public/private keys and certificate signing requests is usually done using software packages such as "OpenSSL".
  • Communication with a CA is usually done through its web site.
  • Incorporation of an SSL certificate into your web site depends on the web server used and typically does not pose too many difficulties.