security quick start guide

Thank you for your interest in the encryption capabilities of OutsideView and the NonStop SSL (NSSL) proxy. This Quick Start Guide includes directions for installing the NSSL components on a NonStop server, starting a secure telnet proxy and configuration of encrypted OutsideView sessions. During the SSL handshake, test certificates included in the NSSL installation will be sent to the OutsideView client, and server authentication will be through validation of the root CA certificate fingerprint.

This simplified installation is intended for test or evaluation purposes only; you should acquire or create server and root CA certificates for any production deployment.

For a comprehensive description of the capabilities and usage of NSSL, please refer to the NonStop SSL (NSSL) Manual.pdf included on the CDROM. Certificate creation tools for both server and root CA certificates are included with NSSL and are served through a NSSL process started as a HTTP server.

 

Architecture

As is the case for any encrypted channel, encryption/decryption services must be active at both ends of the channel. To provide these services on NonStop systems, NSSL can be run as a proxy process to front-end TCP/IP servers accepting plain TCP connections such as the NonStop TELSERV process. With its SSL support, NSSL will enable secure communication to clients that also support the SSL protocol. OutsideView provides these services at client workstations with TCP/IP connectivity to the host system(s).

 

arch

 

NSSL as an SSL proxy front-ending the standard NonStop Telserv process

Acting as a proxy server, NSSL will accept SSL connections from the network and "tunnel" them to a plain TCP server. Encrypted data received from the SSL client will be decrypted and forwarded to the server. Plain data received from the plain TCP server will be encrypted and sent to the SSL client. For example, from the Telnet server's point of view the proxy acts as a normal Telnet client, while from a SSL telnet client the NSSL proxy authenticates the Telnet server and encrypts/decrypts the session's payload.

Typically, a NSSL proxy will reside on the same IP process on the same system as the TCP server it tunnels the session to, which allows creation of a "local loopback" session (a connection to "127.0.0.1") for the unencrypted data. This avoids exposure of any unencrypted data on the network. For a local loopback, the data is only being passed within the local TCP/IP stack.

One instance of a NSSL proxy handles SSL connections received on a single IP process and port number and tunnels them to a single target port. Hence if multiple plain ports need to be secured, such as multiple Telnet Servers, a NSSL process needs to be started for each plain TCP port.

 

Installing NSSL on the NonStop system:

1. Determine the Guardian subvolume to be used for NSSL installation.

 

2.Using your favorite file transfer program, transfer the NSSL installation archive (NSSLINS.100) in binary mode to that subvolume.

 

3. Alter the installation archive file code:

FUP ALTER NSSLINS, CODE 100

 

4. Extract the archive by issuing the following command:

RUN NSSLINS

 

The NSSL program files will now be copied to the current subvolume.

 

Installing the license file

For the run modes that support encryption such as secure telnet, you need a license file from Crystal Point which allows the usage of that run mode. The license file is attached to an email sent by our sales group to a designated contact at your organization. This file should be transferred (in binary format) to the installation subvolume. The license file is tied to your system number.

The license file should be called LICENSE (default if not otherwise specified using the license parameter) and should reside on the same subvolume as the NSSL object file. If you need to put the license file in a different location you must use PARAMETER LICENSE to specify the location. If there is a problem with the license file, NSSL will issue a message and terminate:

Running NSSL as a Secure Telnet Proxy

NSSL is delivered with an example configuration file (SSLCONF), which contains an SSL configuration for testing purposes. Using this configuration file, you can start NSSL as a secure Telnet proxy by a single RUN command.

Note: For a production installation, you should use your own server certificate. Please refer to "Configuring SSL for production" in the "SSL Reference" chapter for details.

To start the NSSL Secure Telnet Proxy:

1. Determine the Telnet server for which you want to install the secure proxy and the TCP/IP process and port number it is listening on. If the TELSERV process is running on TCP/IP process $ZTC0, port 23 issue the following command at the command prompt:

 

RUN NSSL/NAME $STN0/ TELNETS; PORT 8423; CONFIG SSLCONF


otherwise start the proxy with a command such as:

RUN NSSL/NAME $STN03/ TELNETS; SUBNET $ZTC03; PORT 8423; TARGETPORT 1023; CONFIG SSLCONF


where

  • the keyword "TELNETS" designates the NSSL run mode as a secure telnet proxy.

 

  • the parameter "SUBNET" specifies the TCP/IP process NSSL should run on. This should be the same process the TELSERV process runs on. As shown above, you may omit this parameter, in which case NSSL will assume $ZTC0 as default.

 

  • the parameter "PORT" reflects the port number NSSL should listen on for secure Telnet connections.

 

  • the parameter "TARGETPORT" reflects the port number of the TELSERV process the connections should be routed to. As shown above, you may omit this parameter, in which case NSSL will assume the well-known telnet port 23 as default.

 

  • the parameter "CONFIG" refers to the configuration file containing the example SSL configuration delivered with NSSL.

 

NSSL will now start with the parameters specified on the command line. It will output initialization messages to your terminal. Please check these messages for any errors.

 

Configuring OutsideView SSL Sessions

To connect an OutsideView session to the NSSL proxy without errors, the trustworthiness of the certificates received from the NonStop host during the SSL handshake must be verified. OutsideView supports two methods for server authentication; verification against the local certificate store or verification of the fingerprint of the root CA certificate. The NSSL proxy must started using a server certificate with the DNS name of the server as the common name if the verification against the local certificate store method is to be used. Verification of the root CA certificate fingerprint is, therefore, the server authentication method used for this test installation.

To include the root CA certificate fingerprint in the session settings:

1. In the Session Settings I/O tab, select "Encrypt datastream using SSL".

 

2. Select "Validate root CA fingerprint".

 

3. Enter the value "2F179844AE6EB97E439DE79C7F633944". This value is obtained using the certificate tools available by running the NSSL proxy as an HTTP server.

 

Support

If you should encounter any difficulties or have any questions during your evaluation, please do not hesitate to contact our support group at support@crystalpoint.com or +1 (425) 806-1143.