Secure Sockets Layer (SSL) is a protocol that provides a secure connection over an insecure network. It is commonly used by Internet applications such as web-based banking and commerce; whenever you see a URL beginning with https, you know that your web browser is communicating using SSL.
SSL can also be used to secure DRDA connections, and is supported by recent versions of DB2 and some DB2 DRDA clients such as StarSQL 6.0x and StarSQL for Java. However, since SSL support is a recent enhancement to DB2, it is common to find older DB2 servers and clients that do not have SSL support. In addition, the configuration of SSL on a host system like z/OS can be complicated, and the processing of encrypting and decrypting the secure communications requires extra processing power.
StarPipe's SSL support provides a solution for all of these issues - it can act as an SSL proxy for either the client or the host or both, without changes to either client or host, it off-loads the processing load of encryption to a Windows server, and it is simple to configure and manage.
In the following scenarios, the DRDA client and the DB2 server are in different locations, and wish to communicate securely over the Internet using port 448 for encrypted traffic. You may need to configure firewalls to allow communication using port 448, or use a multi-homed StarPipes server with one network interface directly connected to the Internet listening for incoming SSL DRDA traffic.
In this scenario, we have an SSL-enabled DRDA client like StarSQL for Java at a remote site, and a StarPipes server collocated with a DB2 server that does not support (or is not configured for) SSL. The Starpipes server acts as an SSL proxy for the DB2 server.
The SSL-enabled client communicates with StarPipes using SSL (e.g. port 448); StarPipes communicates with the host using unencrypted DRDA (e.g. port 446).
Follow the following steps for this scenario:
Install a StarPipes server certificate; see Certificate Management for details.
Configure a StarPipes SSL listener; see Listeners Properties for details.
Configure a TCP/IP route to the DB2 host (you will need to know the hostname or IP address and listening port of the DB2 host); see Routing Properties.
Configure the SSL-enabled DRDA client; see Listeners Properties for an example of configuring a StarSQL for Java client; see Certificate Management for an example of configuring an IBM i 7.1 server as a client to StarPipes.
In this scenario, we have a StarPipes server collocated with a DRDA client that does not support (or is not configured for) SSL at a remote site, communicating over the Internet with an SSL-enabled DB2 server.
The client communicates with StarPipes using unencrypted DRDA (e.g. port 446), and StarPipes communicates with the host using SSL (e.g. port 448).
Follow the following steps for this scenario:
Create a TCP/IP listener listening on port 446; see Listeners Properties.
Confirm that SSL is enabled on the DB2 host computer. If necessary, contact your DB2 or network administrator to obtain the listening port that the host is using for SSL connections to DB2. See Configuring SSL for DB2 for z/OS, Configuring SSL on DB2 for i, Configuring SSL for DB2 UDB, or Configuring SSL for Apache Derby.
Configure an SSL route to the host; see Routing Properties.
Configure the DRDA client to communicate via TCP/IP to the StarPipes server on port 446.
In this scenario, two StarPipes servers provide a secure tunnel over the Internet in the situation where neither the client nor the DB2 server are configured for SSL. One StarPipes server is collocated with the DRDA client at a remote site; the other StarPipes server is collocated with the DB2 host. This is useful for providing secure communications between two data centers without the need for configuration changes or updates for the client or host.
At the remote site, the client communicates with Starpipes using unencrypted DRDA (e.g. port 446). That StarPipes server communicates over the Internet to another StarPipes server using SSL (e.g. port 448), which in turn communicates with the DB2 host using unencrypted DRDA (e.g. port 446).
Follow the following steps for this scenario.
This example shows the use of a StarPipes client certificate issued by a Certificate Authority trusted by both StarPipes servers; the client certificate is installed on the "client" StarPipes server, and the "server" StarPipes server is configured to require client authentication, providing an additional level of security.
In addition, this example assumes that the StarPipes server at the central site is multi-homed, with one network interface connected directly to the Internet and dedicated to incoming DRDA SSL connections; use the Windows Firewall or another mechanism to block all other ports on this interface.
On the StarPipes server at the remote site (collocated with the DRDA client):
Install a client certificate named StarPipesClient; see Certificate Management.
Create a TCP/IP listener listening on port 446; see Listeners Properties.
Configure an SSL route to the other StarPipes server. You will need to know its IP address or hostname and SSL listening port number (448 in this example). See Routing Properties.
Configure the DRDA client to communicate via TCP/IP to its collocated StarPipes server via port 446.
On the StarPipes server at the central site (collocated with the DB2 host):
Install a StarPipes server certificate; see Certificate Management for details.
Configure a StarPipes SSL listener for port 448. For the IP address of the listener, enter the IP address of the Internet-connected network interface; StarPipes will listen only on this interface. In addition, click SSL Options and select Require Client Authentication. See Listeners Properties for details
Configure a TCP/IP route to the host; see Routing Properties.
SSL uses certificates to provide credentials; See Certificate Management.