HTTP proxy

The HTTP proxy only blocks certain types of outbound Web references and content and does not indicate usage to attempt to protect interior Web servers.

Using the HTTP proxy helps implement NAT because it originates all outbound connections to Web servers. It reuses a single IP address for multiple browser clients.

The HTTP proxy configuration is configured on a per-rule basis in the configuration editor to remove cookies (see also the following limitations section); to block Active-X content; to block or allow all Java content (see the following HTTP proxy limitations); and to block SSL content.

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

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

edit> jar_hash parameters...

Hashes can be added, deleted, listed, or renamed. They are named; you assign the names, which are strings, ephemerally. They are used only for purposes of reference to items when managing them using the jar_hash command.

Signatures can be added, deleted, listed, or renamed. They are named and you assign the names, which are strings, ephemerally. They are used only for purposes of reference to items when managing them using the jar_sig command.

Both the JAR hashes and signatures are actually stored in the vars database.

Currently, there is no provision to create Screen-specific versions of these data items.

HTTP Proxy Limitations

The COOKIE restriction simply removes cookies in both directions, rather than refusing requests to set and get them within the HTTP protocol; this behavior often breaks access to pages that are viewable by simply refusing the cookies, which is how today's modern browsers work.

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

ACTIVEX filtering currently blocks certain types of Java content and does not support certain types of FTP downloads. It multiplexes and demultiplexes URL references that contain explicit port numbers (for example: http://foo.com:12345/), which is good because without the proxy, and lacking a proper www state engine in the kernel, you must either forgo access to such URLs or allow insecure tcpall outbound from all browser hosts.

The proxy provides the option to allow tcpall from the routing-mode Screen outbound, which, in conjunction with the HTTP proxy, affords access to such URLs through the proxy.

However, the HTTP proxy can also have untoward security problems by permitting client host browsers to gain outbound access to systems and ports for which you did not intend.

For example:

# ssadm edit configedit> add address sensitive1 HOST 222.1.1.1edit> add address sensitive2 HOST 222.1.2.2edit> add address sensitive GROUP { sensitive1 sensitive2 }edit> add address browser HOST 222.1.3.3edit> add address router HOST 222.1.254.254edit> add address qe0 RANGE 222.1.254.0 222.1.254.255edit> add address qe1 RANGE 222.1.1.0 222.1.1.255edit> add address qe2 RANGE 222.1.2.0 222.1.2.255edit> add address qe3 RANGE 222.1.3.0 222.1.3.255edit> add address outside GROUP { } { qe1 qe2 qe3 localhost router }edit> add rule sensitive-stuff sensitive sensitive ALLOWedit> add rule telnet sensitive router ALLOWedit> add rule telnet localhost router ALLOWedit> add rule telnet localhost sensitive ALLOWedit> add rule www browser "*" ALLOW PROXY_HTTP

It appears as if sensitive is well protected, but, in fact, the browser can cause the HTTP proxy to access the telnet service of both router and sensitive.

Including the following rule worsens the configuration situation:

edit> add rule "common services" localhost "*" ALLOW

Such a rule affords browser access to any TCP service in any rule with the source localhost (unless contrary DENY rules are created).