When the HTTP proxy starts, it reads its policy files, starts a Java Virtual Machine (JVM) for processing Jar (Java archive) 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 is 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 the rule matched specifies (proxy) user authentication, and if proper user credentials are not present in the request or have expired, the proxy returns a response indicating a need for (proxy) user credentials.
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 not allowed, any cookie responses are deleted.
If SSL is allowed and the connection uses SSL, the connection continues. No further processing can take place, because 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 rule matched specifies (proxy) user authentication, and if proper user credentials are not present in the request or have expired, the proxy returns a response indicating a need for (proxy) user credentials.
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 that 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.
If content scanning has been configured, and once the above-mentioned proxy-based content checks have been performed, the resulting content is passed to the scanner for inspection. The scanner may instruct that the content be blocked, or may alter the content (clean viruses, for example) , or may return it unaltered. Scanning results are given to the user (as being blocked, if so determined). Scanning results are reflected in SunScreen log entries regarding the HTTP request and its results.
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.
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
The following is an example of what you type to manage Jar hashes:
edit> jar_hash parameters |
You can add, delete, list, and rename Jar hashes. You assign names, which are ephemeral strings. Names are used only to reference items when managing them using the jar_hash command.
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.
Jar validation facilities acquire the hash and signature values that are added to the configuration.
ActiveX filtering currently blocks certain types of Java content.