CS 5523 Operating Systems
Laboratory 4 - Spring 2002
A Security Gateway

Objectives:

Overview: In this laboratory you will develop a gateway that provides secure access to web servers behind a firewall. Recall that a gateway is a server-side mechanism for directing, filtering or translating interactions between clients and servers. The secure gateway receives non-authenticated client requests for a resource over a secure socket. The gateway then directs the request to one of its authenticated servers via a regular socket.

This laboratory must be done in Java.

Requirements:

Part I: Simple Gateway to a Fixed Server

In Part I, you will write a gateway that takes three command line arguments: a listening port, a server host name and a server port number. The gateway accepts client requests on the listening port through an SSL server socket. The gateway then reads and forwards the client request to the server host on the specified port, using an ordinary socket. The gateway forwards the response from the server to the client. The gateway closes the connections when either the client or the server close their connection.

The accept on the listening port should be on a loop with new threads created for each request. Why is this a gateway and not a tunnel? Describe a situation when such a gateway might be useful.

Write a client program that initiates an SSL connection (without client authorization). Test Part I by running multiple clients simultaneously. Note: in Part I the server is authenticated by passing it as a command line argument.

Also test your security gateway by using a URL with https in your browser. For example, if your gateway is running on pandora on port 16000, you can give the URL https://pandora.cs.utsa.edu:16000/index.html to access index.html.

Part II: Secure Gateway to a Server Set

In Part II you will modify the gateway so that it keeps a list of authenticated server names and ports. The gateway directs each client request to one of the authenticated servers in a round robin fashion. The gateway now listens on two ports, the client port as before and a server authentication port, for client and server requests respectively. The client requests are handled as in Part I. However, the gateway uses the server authentication port to accept requests from servers that wish to register with the gateway as authenticated servers. The gateway accepts requests on this port through an SSL secure socket. However, in this case the gateway requires that the client (the servers that are trying to be authenticated) be authenticated. Both the client port and the server authentication port are specified as command line arguments to the gateway.

Rather than trying to incorporate the server authentication into your server program, you may write a separate program that registers a server and port with the gateway. In that way you can register ordinary web servers with the gateway without their participation. If your client requests a resource such as index.html, many web servers will work. The list of authenticated servers is a shared resource and should be treated accordingly.

Additional Comments: You should start by setting up and running the TCPSecureServer and TCPSecureClientNoAuth as described in SSLJava.html.

In Part I, you should create a new keystore for the client with a new key pair under your name using keytool. Export a certificate for this pair and add it as a trusted certificate to your copy of the cs5523certs trust store.


Last Revision: April 6, 2002 at 1:15 pm by Kay A. Robbins. This material may be used for educational purposes provided that the source is credited.