WASD Hypertext Services - Technical Overview

This section is not a tutorial on SSL. It contains only information relating to WASD's use of it. Refer to the listed references, 10.4 - SSL References, for further information on SSL technology.

Enhancing privacy with SSL, certificate management and varying browser behaviours is not for the faint-hearted!

The Secure Sockets Layer protocol (SSL) is designed to provide privacy between two communicating applications, in the case of HTTP between the browser (client) and the HTTPd (server). It provides other capabilities, such as client authentication, but these are not considered here. SSL operates by establishing an authenticated, encrypted communication path between the two applications, "wrapping" the entire application protocol, such as HTTP, in a secure link, providing complete privacy for the entire transaction. In this way security-related data such as user identification and password, as well as sensitive transaction information can be effectively protected from unauthorized access.

WASD implements SSL using a freely available software library known as "SSLeay", see 10.3 - SSLeay.

SSL functionality is not supplied with the basic WASD package. In part this is due to the relative bulk of this component, but also considers patent issues and USA export restrictions on some cryptographic technology that would impact the basic package's potential for download out of the USA. For further comment on this aspect check the SSLeay FAQ section "Is this legal?". No recommendations are made by this author on the use of the SSLeay package in any particular locality, except to comment that it is in commercial and non-commercial use in many applications across Europe, North America and Australasia.

The WASD SSL component is available as a separate, easily integrated package, either with complete SSLeay source or just SSLeay object libraries, some SSLeay utility object modules for building executables and WASD support files. Obtain these from the same source as the main package.

SSL Overhead

SSL adds a significant overhead to an HTTP transaction for the following reasons.

• An initial connection establishment, where the client and server exchange cryptographic data and authorize the transaction.
• The transaction transfer, where all application data must be processed by the CPU into an encrypted stream, and back ... very expensive processes.
• The encrypted data contains more bytes than the raw data, increasing network transfer time.
• Other miscellaneous SSL handshaking for the life of the transaction.

For these reasons SSL HTTP is slower and has far greater impact on the server system CPU than standard HTTP and therefore should only be used when transaction privacy is required, not as a general HTTP service. Also, if a general HTTP and an SSL HTTP service is provided on a multi-processor system, with one or other or both experiencing significant traffic, then the two services should be run in separate processes.

SSL Access Control

When authorization is in place (see 9 - Authentication and Authorization) access to username/password controlled data/functionality benefits enormously from the privacy of an authorization environment inherently secured via the encrypted communications of SSL. SSL may be used as part of the site's access control policy, as whole-of-site, see Authentication Policy, or on a per-path basis, see Conditionals and Access Restriction List.

Interoperability

WASD SSL has been tested against the following browsers (if any others are tested please advise the result).

SSL installation creates the major directory HT_ROOT:[SRC.SSLEAY-0_9_0b] containing at the least the SSLeay copyright notice, object libraries, object modules for building executables, example certificates, and some other support files and documentation. If a complete source package has been obtained the tree is considerably larger.

The example HTTPd startup procedure already contains support for the SSL executable. If this has been used as the basis for startup then only the respective boolean needs to be altered to use the SSL rather than the standard executable. The SSL executable supports both standard HTTP services (ports) and HTTPS services (ports). These must be configured using the [service] parameter. SSL services are distinguished by specifying "https:" in the parameter. The default port for an SSL service is 443.

The following example illustrates creating two standard HTTP services, one on the default port 80, another on port 8000, and two SSL services, the first on the default port 443, the second on port 8443.

  [Service]
  alpha.wasd.dsto.defence.gov.au
  alpha.wasd.dsto.defence.gov.au:8000
  https://alpha.wasd.dsto.defence.gov.au
  https://alpha.wasd.dsto.defence.gov.au:8443

The "/SSL" qualifier controls which version(s) of the SSL protocol the server will support; "2", "3" or "23" (i.e. versions 2 and 3, also the default). Using /NOSSL disables the SSL functionality of an SSL executable.

The one further requirement of an SSL server is a certificate. This is located using the HTTPD$SSL_CERT logical name during startup.

SSL Quick-Start

If the basic WASD v5.n package is installed, configured and performing satisfactorily the following steps give a quick outline for support of SSL.

1. UNZIP the WASD SSL package. The ZIP archive will contain brief installation instructions. Use the following command to read this and any other information provided.

     $ UNZIP -z device:[dir]archive.ZIP
   

2. Once UNZIPped it will be necessary to link the executables. This should be performed using the UPDATE.COM

   It assumes a vanilla setup, using the standard directories and account environment described in this document. All sections prompt before performing any action and default to "no". The SSL parameter indicates the SSL components should be processed.

     $ SET DEFAULT HT_ROOT:[000000]
     $ @UPDATE SSL
   

3. Once linked the UPDATE.COM procedure will prompt for permission to execute the demonstration/check procedure.

   It is also possible to check the SSL package at any other time using the FREEWARE_DEMO.COM procedure. It should detect the TCP/IP agent in use (if not specify UCX or NETLIB as a parameter). It is necessary to specify that it is to use the SSL executable. Follow the displayed instructions.

     $ @HT_ROOT:[000000]FREEWARE_DEMO SSL
   

4. Modify server startup procedures.

   • Using pre-existing, non-v5.n Startup

     1. Modify the server startup procedure to INSTALL and the HTTPD80.COM procedure (or equivalent) to use the HTTPD_SSL.EXE executable (or HTTPD_SSL_NETLIB.EXE as appropriate)

     2. Modify the server startup procedure to define a logical HTTPD$SSL_CERT locating the example certificate at HT_ROOT:[EXAMPLE]HTTPD.PEM, for example

          DEFINE /SYS HTTPD$SSL_CERT HT_ROOT:[EXAMPLE]HTTPD.PEM
        

   • Using v5.n Startup

     Modify the "PROVIDE_SSL" symbol to be 1 (or true).

5. Modify the HTTPD$CONFIG configuration file to specify an SSL service. For example the following creates both a standard HTTP service on the default port 80 and an SSL service on the default port 443

     [Service]
     alpha.dsto.defence.gov.au
     https://alpha.dsto.defence.gov.au
   

6. Shutdown the server completely, then restart.

7. To check the functionality (on default ports) access the server via

   • Standard HTTP

       http://host.domain/
     

   • SSL HTTP

       https://host.domain/
     

8. Once the server has been proved functional with the example certificate it is recommended that a server-specific certificate be created using the CA.COM procedure described in 10.2 - Certificate Management. This may then be used by placing it in the appropriate local directory, changing the HTTPD$SSL_CERT logical definition in the startup and restarting the server.

This section is not a tutorial on certificates and their management. Refer to the listed references, 10.4 - SSL References, for further information on this aspect.

Certificates associate a public cryptographic key with the identity of the certificate holder, usually an individual or server. It includes a distinguishing name, identification and signature of the certificate authority (CA, the issuer and guarantor of the certificate), and the period for which the certificate is valid, possibly with other, additional information.

The server uses a certificate to establish it's identity during the initial phase of the SSL protocol exchange. Each server should have a unique certificate. An example certificate is provided with the WASD SSL package. This is the default used by the example startup procedure and will suffice to demonstrate the server's functionality. If a "live" SSL site is required a unique certificate issued by a third-party Certificate Authority is desirable. A working alternative to obtaining one of these certificates is provided by the

HT_ROOT:[SRC.SSLEAY-0_9_0b.WASD]CA.COM

This procedure allows CA as well as server certificates to be issued, as well as providing foreign command symbols for other certificate management utilities. For usage requirements and parameters check the commentary in the procedure preamble.

CA certificates can be loaded into browsers to allow sites using that CA to be accessed by that browser without further dialog. Both Netscape Navigator (v3.n & v4.n) and MS Internet Explorer (v4.n) automatically invokes a server certificate load dialog when it encounters a site using a valid but unknown server certificate.

A manual load is accomplished by requesting the certificate in a format appropriate to the particular browser. This triggers a browser dialog with the user to confirm or refuse the loading of that certificate into the browser Certificate Authority database.

To facilitate loading CA certificates into a browser ensure the following entries are contained in the HTTP$CONFIG configuration file:

  [AddIcon]
  /httpd/-/binary.gif  [BIN]  application/x-x509-ca-cert

  [AddType]
  .CRT  application/x-x509-ca-cert  -  DER certifcate (MSIE)
  .PEM  application/x-x509-ca-cert  -  Privacy Enhanced Mail certificate

The following would load the WASD testing CA certificate in a format suitable for

• Navigator (v3.n, v4.n):

  /ht_root/src/ssleay-0_9_0b/wasd/cacert.pem

• MS Internet Explorer (v4.n):

  /ht_root/src/ssleay-0_9_0b/wasd/cacert.crt

If a site's server or CA certificate is changed and the server restarted any executing browsers will probably complain (Netscape Navigator reports an I/O error). In this case open the browser's certificate database and delete any relevant, permanently stored certificate entry, then close and restart the browser. The next access should initiate the server certificate dialog, or the CA certificate may be explicitly reloaded.

10.3 - SSLeay

WASD implements SSL using a freely available software library known as "SSLeay" (pronounced "S-S-L-E-A-Y", i.e. all letters spelt), authored and copyright by Eric Young and Tim Hudson. It is not a GNU-licensed package, but does makes unrestricted commercial and non-commercial use available. The FAQ for SSLeay may be found at

http://www.psy.uq.oz.au/~ftp/Crypto/

This should be consulted for all information on the SSL technology employed by WASD.

If the SSLeay component of WASD is installed it can be found at

HT_ROOT:[SRC.SSLEAY-0_9_0b]

The previous version of SSLeay, 0.8.1, provided with WASD v5.0.0, can also be linked and will work with WASD v5.1.0. It is preferable to move to SSLeay v0.9.0b as known bugs in the previous version have been fixed in this one (ignoring the issue of new bugs being introduced ;^). If v0.8.1 is installed it will be found at

HT_ROOT:[SRC.SSLEAY-0_8_1]

It has been necessary to make minor modifications to the 0.9.0b distribution to support VMS (there was rudimentary support that looked like a hang-over from a previous distribution). These changes are very minor and designed to address the differences in VMS and DECC versions. All changes to source can be found by searching for "MGD" in [...]*.C, [...]*.H and [...]*.COM files.

These changes have been made only to support WASD's use of the package, they are not proposed as general SSLeay modifications, i.e. they were purely pragmatic!

Our thanks to the authors of and contributors to the SSLeay package, although if there is a documentation boffin out there please contact  eric@CryptSoft.com  :^)

10.4 - SSL References

The following provide a starting-point for investigating SSL and SSLeay further (verified available at time of publication).

• http://www.netscape.com/newsref/std/SSL.html
  Netscape Communication Corporation's SSL Overview

• http://www.psy.uq.oz.au/~ftp/Crypto/
  SSLeay FAQ.

• http://www.camb.opengroup.org/www/prism/wwwj/index.html
  A good introduction to SSLeay.

• http://www.camb.opengroup.org/~fjh/Papers/cook/ssl_cook.html
  An excellent overview of managing certification with SSLeay.

• http://www.consensus.com/security/ssl-talk-faq.html
  SSL-Talk discussion list FAQ