HTTP Proxy Operation

When the HTTP proxy starts, it reads its policy files, starts a Java Virtual Machine (JVM) for processing Jar files, and then listens on the standard HTTP port (80) for connections. When a connection is made, the HTTP proxy starts a new thread to handle the connection, and the main thread resumes listening.

The child thread reads the first line of the HTTP header request from the client and parses the actual destination address. The method (for example, http:// or ftp://) is determined. If the ftp:// method has been requested, the request for file retrieval is forwarded to the FTP proxy as described above. Otherwise (for the http:// method) the thread searches the proxy policy rules for a match on the source and destination addresses.

• If a match is found, the flags associated with that policy rule are set. The proxy then reads the rest of the client's HTTP request. If a match for the connection is not found, the HTTP proxy sends the client an error (Method Not Implemented) and closes the connection.

• If cookies are disallowed, any cookie responses are deleted.

• If SSL is allowed and the connection uses SSL, the connection continues. No further processing can take place, since the rest of the connection is encrypted. If SSL is not allowed, the HTTP proxy drops the connection and sends an error (Method Not Implemented) to the client.

• If the connection is allowed, the HTTP proxy attempts to open a connection to the actual destination web server. If the web server cannot be reached, the proxy returns an error (Cannot locate host) to the client and closes the connection.

• If the HTTP proxy connects to the web server, it sends the client's HTTP request to the server and waits for a response. When a response arrives, the proxy reads the response header and, if appropriate, drops any cookie requests. If the response header indicates the response includes Java or ActiveX content, the proxy examines the response body to determine the nature of the content. If the content is not allowed, the proxy sends an error (Cannot connect to host) to the client and drops the connection.

Java Virtual Machine (JVM)

If the body contains a Jar file, the Jar is passed to the JVM, which extracts the signature components and calculates a hash for the Jar. The signatures are compared to the list of approved signatures and if the signatures match and signed Jars are allowed, the data are passed on to the client. If hashed Jars are allowed, the proxy compares the computed hash to the list of approved hash values, and, if a match is found, passes the response to the client.

After all of the data have been passed to the client, the proxy closes the connections to the client and the server and terminates the thread.

Jar Hashes and Signatures

The HTTP proxy is configured on a global basis in the configuration editor to verify the list of acceptable signatures and hash values on Jar content.

Both the Jar hashes and signatures are stored in the vars database.

Currently, there is no provision to create Screen-specific versions of the Jar hashes and signatures for the Screen

Jar Hashes

The following is an example of what you would type to manage Jar hashes:

edit> jar_hash parameters ...

You can add, delete, list, and rename Jar hashes. You assign the names, which are ephemeral strings. They are used only for purposes of reference to items when managing them using the jar_hash command.

Jar Signatures

You can add, delete, list, or rename Jar signatures. You assign the names, which are ephemeral strings. The names are used only for purposes of reference to items when managing them using the jar_sig command.

HTTP Proxy Limitations

Jar validation facilities acquire the hash and signature values that are added to the configuration.

ActiveX filtering currently blocks certain types of Java content.