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.