The HTTP proxy provides a relay capability for HTTP access to the World Wide Web. This relay supports HTTP and the Secure Sockets Layer (SSL). The HTTP proxy allows or denies sessions based on the source and destination addresses. Additionally, the HTTP proxy provides selective filtering of HTTP content, such as Java applets, ActiveX, and cookies, based on the source and destination addresses for sessions. Finally, the HTTP proxy can filter Java applets based on the signatures encapsulated in Java Archive (JAR) files attached to the applet or based on a precomputed hash of valid applets.
To use the HTTP proxy, define the source addresses that should be allowed to access the proxy and the destination addresses of allowed Web servers to be contacted. To create the HTTP proxy rule, use the built-in service www, reference your desired source and destination addresses, and select the PROXY for PROXY_HTTP during rule definition (in the administration GUI) or the PROXY_HTTP keyword (for command-line rule creation).
The HTTP proxy allows further restrictions based on target port numbers. HTTP provides for user-specified references to arbitrary port numbers using the http://host:port/... construction. Because of the way in which the Screen operates, client browsers can be inadvertently allowed to access services that would otherwise be restricted save this feature of HTTP.
The port restriction mechanism for the SunScreen EFS 3.0 HTTP proxy is controlled by the variable TargetSvcs. This variable can either be global or Screen-specific. It contains the following items:
sys=Screen (optional)
prg=httpp
name=TargetSvcs
values={ svc=service ... }(name(s) of service objects for services to allow)
description="descriptive text"(optional)
enabled | disabled (default is enabled)
As initially-installed, a global version of this variable is created that restricts such access to port 80 (the www service).
The following is an example of what you type to display this (initial) variable while logged into the primary Screen:
admin% ssadm -r primary edit Initial edit> vars print prg=httpp name=TargetSvcs PRG="httpp" NAME="TargetSvcs" ENABLED VALUES={ svc="www" } DESCRIPTION="target TCP ports that the HTTP proxy can get to" |
You may wish to be able to access a wider range of ports in their URLs. One such configuration is obtained by configuring a new service object and an added variable (for example, this time, for a particular Screen) Again, the following is an example of what you type while logged in to the primary Screen:
admin% ssadm -r primary edit Initial edit> add service www-targets SINGLE FORWARD "tcp" PORT 1024-1520 PORT 1522-3850 PORT 3856-5999 PORT 6064-65545 COMMENT "more TCP port numbers to allow as targets in HTTP proxy URIs" edit> vars add sys=screen prg=httpp name=TargetSvcs values={ svc=ssl svc=www svc=www-targets } description="target TCP ports that the HTTP proxy can get to" edit> save edit> quit |
The above definitions prevent access to ports that are below 1024 except for www and ssl. It also prevents access to port 1521 (SQLNET), ports 3851-3855 (the Screens administrative and SecurID PIN server ports), and ports 6000-6063 (used by X windows). Tailor your restrictions to suit your security needs.
The SunScreen EFS 3.0 HTTP proxy can also be configured to restrict Web content to be allowed through. Content can be blocked or allowed, or it can be configured to verify certain content (Java applets) based on digital signatures or hashes. These content-filtering features are configured as part of the rules employing the HTTP proxy.
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. It then 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 clients 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 clients 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 (Cant connect to host) to the client and drops the connection.
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 is 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 has been passed to the client, the proxy closes the connections to the client and the server and terminates the thread.