HTTP Proxy

The HTTP proxy as currently implemented is a means of filtering Web content for outbound references from Web browsers to external, unknown servers. It does not have the ability to restrict inbound access such as user access control.

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).

• Allows or denies sessions based on the source and destination addresses.

• Provides selective filtering of HTTP content (such as Java applets, ActiveX, and cookies) based on the source and destination addresses for sessions.

• Is useful in implementing NAT because it originates all outbound connections to Web servers. It reuses a single IP address for multiple browser clients.

• Can filter Java applets based on the signatures encapsulated in Jar files attached to the applet or based on a precomputed hash of valid applets.

• Is configured on a per-rule basis in the configuration editor to:

  • Remove cookies (see "HTTP Proxy Limitations")

  • Block ActiveX content

  • Block or allow all Java content (see "HTTP Proxy Limitations")

  • Block SSL content.

To use the HTTP proxy, define the source addresses that should be allowed to have access to the proxy and to 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 access to services that would otherwise be restricted save for this feature of HTTP.

The port restriction mechanism for the SunScreen 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 or names of service objects for services to allow)

• description="descriptive text" (Optional)

• enabled | disabled (The 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 would 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 have access to a wider range of ports. One such configuration is obtained by configuring a new service object and an added variable (for example, this time, for a particular Screen). The following is an example of what you would 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  \ 
srv=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 through 3855 (the Screen's administrative and SecurID PIN server ports), and ports 6000 through 6063 (used by X Windows). Tailor your restrictions to suit your security needs.

The SunScreen 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.

HTTP -> FTP Proxy: The ftp:// Method

The HTTP proxy relays access for the ftp:// method to the FTP proxy. This enables users of the browser to list directories and download files. Most often, this facility is employed in conjunction with URLs embedded in web content designed to facilitate file downloading.

The standard form of an ftp:// method URL is as follows:

ftp://user:passwd@host:port/path...type

The user, passwd, port, and type are optional (and not often used by ftp:// method references.) The list of dir components specifies path name of the reference. SunScreen does not implement the port option for ftp:// URLs.

The default behavior of the user and passwd references is to use "anonymous" FTP. A typical URL would then look like:

ftp://codebloat.com/pub/dwnlds/exploder5.exe

Control over the defaulting of user and passwd is obtained using three variables.

1. FtpPwdDomain contains the following items:

• sys=screen (Optional)

• prg=http

• name=FtpPwdDomain

• value=domain (domain is used in creating an anonymous password.)

• description="descriptive text" (optional)

• enabled | disabled (The default is disabled.)

  The HTTP proxy will default this variable at run-time (if not found, or disabled) to be the domain name of the Screen (for example, the output of the Solaris defaultdomain command).

1. FtpPwdUser contains:

• sys=screen (Optional)

• prg=http

• name=FtpPwdUser

• value=user (user is used in creating an anonymous password. The default is webproxy.)

• description="descriptive text" (Optional)

• enabled | disabled (The default is enabled.)

  The HTTP proxy will use this variable, in conjunction with the (perhaps defaulted) value of FtpPwdDomain to construct an anonymous password of the form:

  @FtpPwdUser@FtpPwdDomain

  If the passwd supplied in the URL is a string that contains no @ characters (encoded as  %40), then that passwd string takes the place of the value of FtpPwdUser in the anonymous password construction. Thus the URL:

  ftp://:bob@codebloat.com/pub/dwnlds/exploder5.exe

  enables designating the user bob for the user portion of the anonymous password (for example, @bob@FtpPwdDomain).

  The value of the FtpPwdUser can be changed to redirect potential email responses from FTP servers to an appropriate storage receptacle.

1. FtpUser contains:

• sys=screen (Optional)

• prg=http

• name=FtpUser

• value=proxyuser (proxyuser is used in anonymous access. The default is anonymous.)

• description="descriptive text" (Optional)

• enabled | disabled (The default is enabled.)

  This variable would not normally need to be altered, unless the identity of the predefined user anonymous in the Screen's proxyuser database has been changed.

  In addition to the anonymous usage, it is possible to download using authenticated users through the FTP proxy using the ftp:// method. An example URL is:

  ftp://proxyuser:proxypass%40serverpass@server/README.TXT

  This performs an operation identical to a direct interaction with the FTP proxy, supplying the user as proxyuser@server and the password as proxypass@serverpass.

To enable the HTTP proxy to use the ftp:// method, one or more rules are needed to allow the HTTP proxy itself to be a client of the FTP proxy. The HTTP proxy always connects to the FTP proxy using the LOOPBACK (127.0.0.1) address. So, for example, to enable the ftp:// method anonymous access to "outside" web servers:

edit> add address outside ...
edit> add address local127 RANGE 127.0.0.1 127.255.255.255 ...
edit> add rule ftp local127 outside ALLOW PROXY_FTP USER anonymous PROXY_FTP GET CHDIR ...

This enables anonymous FTP through the proxy for any user actually on the Screen itself as well.

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.