SSL and G&R products

Introduction
A short introduction to public-key encryption and certificates
SSL functionality
Getting started
Supplied files
Host Links
Glink
Obtaining a valid certificate
For demo purposes
For production systems
Obtaining certificate from a third party issuer
Creating your own requests & certificates
Using XCA to create a certificate request
How to request a test certificate from Thawte
Setting up your own CA with XCA
OpenSSL license terms

Introduction

The Secure Socket Layer (SSL) protocol was developed by Netscape to ensure secure communication between web servers and browsers. The protocol relies on the use of public-key (asymmetric) encryption and certificates to identify the server and browser.

A short introduction to public-key encryption and certificates

Public-key encryption uses two keys, one public and one private. Data encrypted with the public key can only be decrypted with the private key and vice versa. This encryption scheme can be used for both security and identification.

By using a public key to encrypt data you can ensure that only the owner of the private key can access the data later on. And the other way around - the owner of a private key can encrypt his data with this key. The public key can then be used to verify that the data originated from that particular person.

For this kind of encryption to be useful in practical applications it is vitally important that:

  1. There is a way to securely identify a public key.
  2. The private key is kept private.

In order to identify a public key the concept of certificates and Trusted Parties have been introduced. A certificate is just a way of packaging public keys. It contains information about the owner, intended use, lifespan etc. It will also contain information about the issuer and a stamp verifying its validity.

Keeping the private key private is left to the user, but by default most systems generate private keys that are protected by a password (and encrypted by a safe symmetric encryption algorithm - like 3DES).

SSL functionality

In short, SSL works the following way:

  1. A client connects to a secure server.
  2. The server sends its certificate including the public key.
  3. The client checks that the certificate was issued by a trusted party (usually a trusted root CA), that the certificate is still valid and that the certificate is related to the site contacted.
  4. If using client authorization, the same procedure is reversed and repeated.
  5. The client then uses the server's public key to encrypt a random symmetric encryption key (using one of several available symmetric encryption algorithms e.g. 3DES). It then sends this symmetric key to the server.
  6. The server decrypts the symmetric encryption key using its private key.
  7. The rest of the connection now run with all data between client and server encrypted by the symmetric encryption key.

Getting started

Supplied files

ca.crt:
The issuer (CA) certificate. This is the root certificate of the other certificates. The private key is not supplied.
ggate.pem:
A sample certificate and corresponding private key fcaor use with ggate.
gwebs.pem:
Ditto for gweb
glink.p12:
A sample client certificate for use with Glink.

Note: These certificates are for demo purposes only. They are not secure in any way.

Host Links

To start ggate/ssl using ggate.pem as the server certificate use:

gg_tcp -sslcf ggate.pem

This will start ggate in ssl mode using ggate.pem as a server certificate.

To start gweb/ssl using gwebs.pem as the server certificate use:

gwebss -sslcf gwebs.pem

or add the parameter 'SSLCertificateFile gwebs.pem' to gwebs.ssl.

This basic way of starting Ggate/Gwebs with SSL ensures that the Clients (Glink/Browser) can make certain that they are talking to the correct host, and all traffic between them will be encrypted.

If you want to secure the server further so that only connections from valid clients are accepted, you can use the –sslca parameter. The file specified by -sslca contains one or more issuer certificates. When this parameter is in use the server will ask the client for a certificate during connect, and will allow only clients with valid certificates issued by issuers found in the file specified. E.g.

gg_tcp –sslcf ggate.pem –sslca ca.crt

will only allow connections from clients with certificates issued by the G&R demo CA (ca.crt).

Glink

Glink uses certificates present in the standard Windows certificate store. The supplied glink.p12 certificate can be imported into windows by either double-clicking it, or from Internet Explorer using Tools->Internet Options->Content->Certificates. This file is password protected and the password is 'glink'.

Obtaining a valid certificate

For demo purposes

The supplied ggate/gweb certificates are generic certificates. When clients try to authenticate servers they usually look in the "Common Name" (CN) field in the certificate to see if it matches the DNS (Internet) name of the server.

On request G&R can supply you with server certificates that contain a server name of choice, making it possible for the client to correctly identify your server. Note that this certificate will still not be secure and should not be used in a production environment.

For production systems

Production systems should be run with certificates that are considered secure. That means certificates issued by a trusted third party, or internally issued certificates that can be trusted within an organization.

Obtaining certificate from a third party issuer

There are several third party certificate authorities. Among the most popular ones are:

In order to obtain a certificate from any of these CAs you must create a valid certificate request (CSR). There are several ways to do this. See below for an explanation of using the XCA program to create the request.

Creating your own requests & certificates

In order to issue your own certificates you must obtain the necessary tools to set up a Certificate Authority and issue new certificates using this CA. These certificates can be considered secure within an organization. Unfortunately there are currently not very many good tools for certificate maintenance and those available are often very limited or very complex.

We have been using XCA (http://www.hohnstaedt.de/xca.html) to create the certificates. This is a windows based tool, which is configurable and relatively easy to use. It lets you set up one or more Certification Authorities, and create new server or client certificates using these CAs.

Using XCA to create a certificate request

How to request a test certificate from Thawte

In order to test the CSR created you can request a test certificate from Thawte. Test certificates will be issued by an unknown (insecure) CA and will be valid for only 3 weeks, but they are instantly available.

Setting up your own CA with XCA


OpenSSL license terms

The Gweb and Host Links products from Gallagher & Robertson include software developed by the OpenSSL Project for use in the OpenSSL Toolkit.

The OpenSSL toolkit stays under a dual license, i.e. both the conditions of the OpenSSL License and the original SSLeay license apply to the toolkit. See below for the actual license texts. Actually both licenses are BSD-style Open Source licenses. In case of any license issues related to OpenSSL please contact [email protected].

The license terms are quoted below.

OpenSSL license

/* ====================================================================
 * Copyright (c) 1998-2003 The OpenSSL Project.  All rights reserved.
 *
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions
 * are met:
 *
 * 1. Redistributions of source code must retain the above copyright
 *    notice, this list of conditions and the following disclaimer. 
 *
 * 2. Redistributions in binary form must reproduce the above copyright
 *    notice, this list of conditions and the following disclaimer in
 *    the documentation and/or other materials provided with the
 *    distribution.
 *
 * 3. All advertising materials mentioning features or use of this
 *    software must display the following acknowledgment:
 *    "This product includes software developed by the OpenSSL Project
 *    for use in the OpenSSL Toolkit. (http://www.openssl.org/)"
 *
 * 4. The names "OpenSSL Toolkit" and "OpenSSL Project" must not be used to
 *    endorse or promote products derived from this software without
 *    prior written permission. For written permission, please contact
 *    [email protected].
 *
 * 5. Products derived from this software may not be called "OpenSSL"
 *    nor may "OpenSSL" appear in their names without prior written
 *    permission of the OpenSSL Project.
 *
 * 6. Redistributions of any form whatsoever must retain the following
 *    acknowledgment:
 *    "This product includes software developed by the OpenSSL Project
 *    for use in the OpenSSL Toolkit (http://www.openssl.org/)"
 *
 * THIS SOFTWARE IS PROVIDED BY THE OpenSSL PROJECT ``AS IS'' AND ANY
 * EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
 * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
 * PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL THE OpenSSL PROJECT OR
 * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
 * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
 * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
 * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
 * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
 * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
 * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
 * OF THE POSSIBILITY OF SUCH DAMAGE.
 * ====================================================================
 *
 * This product includes cryptographic software written by Eric Young
 * ([email protected]).  This product includes software written by Tim
 * Hudson ([email protected]).
 *
 */

Original SSLeay license

/* Copyright (C) 1995-1998 Eric Young ([email protected])
 * All rights reserved.
 *
 * This package is an SSL implementation written
 * by Eric Young ([email protected]).
 * The implementation was written so as to conform with Netscapes SSL.
 * 
 * This library is free for commercial and non-commercial use as long as
 * the following conditions are aheared to.  The following conditions
 * apply to all code found in this distribution, be it the RC4, RSA,
 * lhash, DES, etc., code; not just the SSL code.  The SSL documentation
 * included with this distribution is covered by the same copyright terms
 * except that the holder is Tim Hudson ([email protected]).
 * 
 * Copyright remains Eric Young's, and as such any Copyright notices in
 * the code are not to be removed.
 * If this package is used in a product, Eric Young should be given attribution
 * as the author of the parts of the library used.
 * This can be in the form of a textual message at program startup or
 * in documentation (online or textual) provided with the package.
 * 
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions
 * are met:
 * 1. Redistributions of source code must retain the copyright
 *    notice, this list of conditions and the following disclaimer.
 * 2. Redistributions in binary form must reproduce the above copyright
 *    notice, this list of conditions and the following disclaimer in the
 *    documentation and/or other materials provided with the distribution.
 * 3. All advertising materials mentioning features or use of this software
 *    must display the following acknowledgement:
 *    "This product includes cryptographic software written by
 *     Eric Young ([email protected])"
 *    The word 'cryptographic' can be left out if the rouines from the library
 *    being used are not cryptographic related :-).
 * 4. If you include any Windows specific code (or a derivative thereof) from 
 *    the apps directory (application code) you must include an acknowledgement:
 *    "This product includes software written by Tim Hudson ([email protected])"
 * 
 * THIS SOFTWARE IS PROVIDED BY ERIC YOUNG ``AS IS'' AND
 * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
 * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
 * ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
 * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
 * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
 * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
 * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
 * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
 * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
 * SUCH DAMAGE.
 * 
 * The licence and distribution terms for any publically available version or
 * derivative of this code cannot be changed.  i.e. this code cannot simply be
 * copied and put under another distribution licence
 * [including the GNU Public Licence.]
 */