Using the PicLan-IP Web Server with SSL

May 30, 1998

This document is very preliminary in nature. Of the techniques discussed here, the only "supported" method is to use the REDIR.EXE program to redirect CGI output from IIS.

Modular Software is working on a number of solutions to allow users to run secure web sites using PicLan-IP. These solutions should allow users to deploy secure web sites with minimal expense and good performance while maintaining the ease of deployment and programming of the PicLan-IP product.

The SSL "Road Map" for PicLan-IP

Modular Software will be introducing a number of enhancements to the PicLan-IP product to allow secure transactions. These enhancements are being released in steps to provide the maximum benefit to our customers while maintaining the feature set of the PicLan-IP product suite.

The first SSL enabling enhancement to be released is an SSL "redirector" that allows PicLan-IP to sit behind an SSL enabled server. Initially, this redirector is being implemented as a Win32 application that runs using CGI. We are testing this redirector with Microsoft Internet Information Server (IIS) version 4.0, but it's design is such that it should work with most Windows NT/95 web servers that support CGI. The PicLan-IP redirector should be available starting next week.

After the CGI based redirector has been released, Modular Software will be looking at higher-performance and more tightly integrated solutions. The solutions being investigated include:

Integrating SSL directly into PicLan-IP using license RSA algorithms
Integrating SSL directly into PicLan-IP using Microsoft's "crypto API".

This approach only works on Win32 platforms.

Integrating SSL directly into PicLan-IP using RSA algorithms after RSA's patents expire next year
Integrating the PicLan-IP SSL web redirector using ISAPI and/or NSAPI to improve performance
Integrating a redirector layer for use with Secure/Apache on Linux and perhaps other platforms
Building integration layers for use with SSL capable reverse proxy servers such as Microsoft Proxy Server and Secure/Apache/Squib

It should be noted that each of these approaches provides only marginal performance and almost no functionality gains over the simple PicLan-IP SSL CGI redirector.

The PicLan-IP SSL CGI Redirector

Traditional web servers support the ability to call application programs (either executables or scripts) through an interface called the Common Gateway Interface or CGI. The PicLan-IP SSL Redirector is a small Win32 application that when called by a traditional SSL enabled web server will redirect that call to a PicLan-IP web server over a non-encrypted HTTP connection. This allows you to run PicLan-IP web application that are secure over the internet even though PicLan-IP does not directly support SSL.

Is this really secure?

The first question that may come to mind is if this configuration is really secure. The answer is yes provided that you insure several elements:

You must be in physical control of the connection between the secure web server and the PicLan-IP web server. This means that you should not use a secure web server that is located elsewhere on the internet.
You must insure that the secure portions of your MultiValue application running on PicLan-IP only accepts connections from the secure web server's redirector and requires that these connections are encrypted.

The first issue is very easy to accomplish. You can either:

Run the secure web server and PicLan-IP (in the case of NT hosted MultiValue platforms) on the same host.
Run the secure web server and PicLan-IP on a single ethernet or fast ethernet segment that does not have "breachable" hosts that could potentially "packet sniff" the network wire.

The possibility of someone breaching a local host for the purposes of packet-sniffing the local network is actually very difficult and unlikely. In any case, directly hacking into the MultiValue host is probably easier in most cased.

The second issue is also easy to accomplish using items that the PicLan-IP SSL redirector provide:

You must insure that secure transactions come only from the IP address of the secure web server.

You check this information by looking at the ST$RIP address in your web applications
This address cannot be "spoofed" by the client and is always the actual connection end-point of the HTTP TCP/IP steam.

You should insure that the connection to the external server is encrypted by looking at the HTTPS server fields that the redirector supplies:

HTTPS_KEYSIZE - 40 or 128 indicating the level of stream encryption
HTTPS_SECRETKEYSIZE - usually 1024 indicating the size of the public/private key pairs
HTTPS_SERVER_ISSUER - Information about who issues the servers certificate
HTTPS_SERVER_SUBJECT - Information about who is using the server certificate
SERVER_PORT_SECURE - 1 indicating a secure connection

Configuring the PicLan-IP SSL Redirector

What you need to do with IIS.

The first step is to setup IIS for secure communications. This involves not only setting up IIS keys, but also getting a certificate from a public certificate authority like Verisign or Thawte. More information about setting up IIS for this purpose is the topic of another document that will be available in the near future.

After IIS is setup and will accept secure connections, you must make the PicLan-IP redirector program an executable program within a virtual directory of the IIS director structure. The recommended proceedure is to create a directory named /PICLAN-IP/ that points to a directory on the 'C' drive named c:\plip-rdr\. You will need to give this directory execute priviledges.

After you setup the c:\plip-rdr\ directory, you will need to copy the REDIR.EXE program into it. If you wish you can rename this program when you copy it and there are even some scenarios where you might want to place multiple copies into the target directory.

Configuring the REDIR.EXE Program

The REDIR.EXE program is controlled by registry entries. You need to run the REGEDIT program and create a new set of keys called:

HKEY_LOCAL_MACHINE
    SOFTWARE
        Modular Software
            PicLan-IP
                REDIR

Under this registry root, you can create any number of redirection rules. Each redirection rule consists of a string value with a key name of:

http{s}://ip_addr:port{/path}/{exename}

With the example given here, you would create a key with a name of:

https://207.215.231.1:443/plip-rdr/redir.exe

This assumes that the secure server is running on 207.215.231.1 and on port 443 (the default for HTTPS). It is possible to redirect non-secure (http) connections, but this serves no purpose as PicLan-IP is much more efficient at servicing these requests directly.

When a request is encountered, the value of the registry key controls where the REDIR.EXE program will redirect this to. The format of this value is:

http://ip_addr:port{/path}

In this case, you would want to configure this as:

http://207.215.231.1:80/secure

This will cause HTTPS requests for:

https://secure.modsoft.com/plip-rdr-redir.exe/app/app1.htm

to be redirected to:

http://207.215.231.1/secure/app/app1.htm

You should then place your secure application in the /secure/app/ subdirectory under PicLan-IP.

Configuring your Application for SSL

Once you have redirected an SSL server to your application, you still need to be sure that the SSL redirection is actually used. You do this by including mv/BASIC code in your application that verifies:

The ST$RIP field contains the IP address of the SSL server (or servers)
The HTTPS_... header fields contain adequate encryption values (such as 128 bit for bank transactions)

When you configure SSL applications, you need to consider ways of optimizing your application:

SSL connections are much slower than non-SSL connections
The CPU overhead of SSL on a web server can be severe.

For these reasons, you should be careful to:

Only use SSL for pages that actually contain sensitive data

You must use SSL for in-line images on a page even if the image itself is not sensitive. Most browsers require that all documents on a page transfer over a secure connection if the main document is secure.
Do not use SSL for pages that do not actually contain live sensitive data even if they are a part of an application that has some sensitive pages.