[Top] [Prev] [Next] [Last]
Download PDF:   US   UK
Download Postscript:   US   UK
Stronghold Web Server 2.4.1 Administration Guide
Chapter 4

Proxy Service

Normally, a server fulfills requests by returning files from within its own directory tree. A proxy server fulfills requests by relaying them to other servers, receiving the requested material, then passing it back to the client. It acts on behalf of the client and other servers. Stronghold Web Server comes with a caching proxy module that supports the HTTP/1.0, FTP, and CONNECT protocols. The proxy module is compiled by default when you install the server.

Figure 4-1: A Proxy Server

Stronghold Web Server's proxy module can function in two modes:

In either case, the proxy can perform either secured (HTTPS) or unsecured (HTTP) transactions on either the client side or the server side. Netscape Navigator and Microsoft Internet Explorer do not support client-side SSL/TLS transactions under normal proxy service, but client-side SSL/TLS transactions are supported under mirror proxy service. You can configure the proxy server to perform SSL/TLS or nonsecure transactions on the server side, regardless of client-side limitations.

The proxy server can also save time by caching requested files. With all recently-requested documents in cache, Stronghold can quickly fulfill repeat requests without waiting for responses from remote servers.

When setting up the proxy, keep these guidelines in mind:

This chapter shows you how configure the proxy and activate caching, then explains how to set up



Configuring the Proxy Server

In order to enable normal proxy service, you only need to have ProxyRequests set to "on." This section shows you how to configure caching and mirror proxy service.

To configure the proxy once it is enabled, use this special container:

<Directory proxy:*>
 . . .
</Directory>

Any directives that you want to use to control the proxy server's behavior should go inside this container. For example, if you want to implement basic authentication for the proxy server, you can add the following to httpd.conf:

<Directory proxy:*>
 AuthType Basic
 AuthUserFile ServerRoot/proxy/.htpasswd
 AuthName Proxy
 require valid-user
 </Directory>

Under this configuration, only users with valid logins and passwords in the .htpasswd file can use the proxy server.

The wildcard is a placeholder for the requested URL, so that a request for http://www.c2.net/ translates to

<Directory proxy:http://www.c2.net/>

You can specify all or part of a requested URL in order to establish configurations for specialized purposes. For example, you can specify a protocol in order to separate different configurations for different protocols:

<Directory proxy:http:*>
 . . .
</Directory>

 <Directory proxy:https:*>
 . . .
</Directory>

The container can also include POSIX extended regular expressions. You can use these to specify the SSL/TLS and nonsecure port numbers. For example, you need both of these containers to configure the default nonsecure port:

<Directory ~ proxy:http://[^:/]+:80/.*>
 . . .
</Directory>

 <Directory ~ proxy:http://[^:/]+/.*>
 . . .
</Directory>

Similar containers denote the default SSL/TLS port:

<Directory ~ proxy:https://[^:/]+:443/.*>
 . . .
</Directory>

 <Directory ~ proxy:https://[^:/]+/.*>
 . . .
</Directory>

Since the remote servers perform all file preprocessing and directory index generation, some directives do not work within the <Directory proxy:*> container. In general, transfer-related directives (such as logging and security directives) work, while content-related directives have no effect.

You also have the option to create a separate virtual host exclusively for proxy server. In that case, the directives should go inside the proxy host's <VirtualHost> container:

<VirtualHost proxy.host.com:*>
 . . .
</VirtualHost>


Caching

The cache directives, described in more detail in "Proxy Service and Caching" on page 7-29, are as follows:

Cache Directive Description
CacheRoot The root cache directory, usually ServerRoot/cache
CacheSize The maximum size of the contents of CacheRoot
CacheGcInterval The interval at which Stronghold Web Server checks the size of CacheRoot to see if it exceeds CacheSize
CacheMaxExpire The maximum period for which Stronghold Web Server caches documents without checking their source for changes
CacheLastModifiedFactor The factor used in the formula that determines when a file expires if it did not come with its own expiry time
CacheDefaultExpire The default expiry time for documents retrieved via protocols that do not support expiry times
NoCache Hosts, domains, or URI keywords that Stronghold Web Server does not cache

In order to disable caching, you can

ProxyRequests and the cache directives are included in the default configuration file, commented out. To use their default values, which work well for almost everyone, simply uncomment them. You can modify them to suit any configuration.



Configuring a Mirror Proxy

The mirror feature is controlled by the ProxyPass directive, which is not affected by ProxyRequests. ProxyPass maps remote servers into the space of the local server transparently, so that a remote site can appear to be part of the local site.

For example, C2Net's main server configuration includes this line:

ProxyPass /apache/ http://www.apache.org/

C2Net's Stronghold server responds to requests for http://www.c2.net/apache/ by passing the request to http://www.apache.org/, then returning the result to the client. However, unlike a regular proxy transaction, ProxyPass causes the browser to show the local URL-http://www.c2.net/apache/-as the location of the requested files.

This method is appropriate only if all HTML references in the remote files are relative (i.e., they do not begin with http:// or https://). If the remote site includes absolute references, images may not appear and links may not work. In that case, use the mirror feature with a virtual host instead. This has the additional effect of making mirrored sites appear separate from your main host. For example:

<VirtualHost apache.c2.net:80>
 ProxyPass / http://www.apache.org/
 </VirtualHost>

 <VirtualHost apache.c2.net:443>
 SSLFlag on
 ProxyPass / http://www.apache.org/
 </VirtualHost>

In this case, Stronghold responds to all requests for apache.c2.net by passing them to www.apache.org, then passing them back to the client. The client shows apache.c2.net as the host being accessed.



Proxying to Other Proxies

Since the proxy module is currently limited to HTTP/1.0, FTP, and CONNECT, you may want to set another proxy to handle requests for other protocols, such as GOPHER. Instead of instructing users to set different proxies for different protocols, you can configure Stronghold Web Server to contact other proxies for requests it cannot fulfill. Users can then direct all requests to Stronghold Web Server. To do this, you can use the ProxyRemote directive in a variety of ways:

ProxyRemote gopher http://www.proxy.net/
 ProxyRemote *://www.emi.com https://www.proxy.com/
 ProxyRemote * http://transend.cs.berkeley.edu:4444/
NOTE: Because ProxyRemote only supports HTTP, all requests and responses that follow other protocols are HTTP-encapsulated. The other proxies that Stronghold Web Server connects to must support the HTTP proxy scheme.

You can also block sites to prevent users from accessing them through the proxy server. The ProxyBlock directive lets you specify a space-separated list of hosts, domains, or URI keywords that the proxy server blocks. For example:

ProxyBlock www.solidoak.com cyberpatrol.com censored

In this example, the proxy blocks all requests for www.solidoak.com, any host in the cyberpatrol.com domain, and any URI that includes the string "censored."

You can also use this directive to block access to all sites, like this:

ProxyBlock *

You can achieve a similar effect by setting ProxyRequests to "off."



Examples

Proxy service can be configured in a wide variety of ways. The examples in this section shows you a few simple configurations for common proxy service scenarios:



An HTTP-to-SSL/TLS Proxy

If the clients on your internal network do not support SSL or TLS, you can use Stronghold Web Server to turn their regular HTTP transactions into SSL/TLS transactions when those transactions reach the Internet. You can also use it to substitute strong ciphers if the clients on your internal network support only weak ciphers. In order to prevent external clients from bypassing the SSL/TLS proxy and conducting unsecured transactions, your network configuration must confine Internet access to the firewall, where the proxy resides.

Figure 4-2: HTTP-to-SSL/TLS Proxy

In this case, the proxy should perform only SSL/TLS transactions when communicating with hosts on the Internet.:

<Directory proxy:http:*>
 order allow,deny
 allow from none
 deny from all
 </Directory>


An SSL/TLS-to-HTTP Proxy on One Platform

If you have a Web server that does not support SSL or TLS, you can use Stronghold Web Server to perform SSL/TLS transactions on behalf of your server. In order to ensure reasonable security, the unsecured server must be

This section describes how to set up an SSL/TLS-to-HTTP proxy on the same platform as your nonsecure server.

NOTE: An SSL/TLS proxy to a nonsecure server over the Internet can provide anonymity, but not data security.

When the two coexist on the same platform, you can use the hostnames that are already associated with that IP number so that proxy transactions are transparent.

Figure 4-3: SSL/TLS-to-HTTP Proxy on a Unified Platform

While the unsecured server listens on port 80, the proxy can handle all transactions on port 443:

Port 443
 Listen 443

 SSLFlag on

 ProxyRequests On
 ProxyPass / http://unsecured.host.com/

You can add a similar <VirtualHost> container for each virtual host on the nonsecure server:

<VirtualHost 1.host.com>
 ProxyPass / http://1.host.com/
 </VirtualHost>

 <VirtualHost 2.host.com>
 ProxyPass / http://2.host.com/
 </VirtualHost>

The proxy passes all SSL/TLS requests for those hosts to port 80, then returns the response as an SSL/TLS transaction. Similarly, you can configure the two servers so that the only access to the unsecured server is through Stronghold Web Server.



An SSL/TLS-to-HTTP Proxy on Separate Platforms

If you have a Web server that does not support SSL or TLS, you can use Stronghold Web Server to perform SSL/TLS transactions on behalf of your server. In order to ensure reasonable security, the unsecured server must be

This section describes how to set up an SSL/TLS-to-HTTP proxy on a platform that is separate from your nonsecure server. Keep in mind that the nonsecure server must be confined to your local network.

NOTE: An SSL/TLS proxy to a nonsecure server on the Internet can provide anonymity, but not data security.

Assuming that the two servers already reside on separate hardware platforms with separate IP numbers, you must first

Figure 4-4: SSL/TLS-to-HTTP Proxy to a Separate Platform

You can then use the hostname of the unsecured server as a virtual host in Stronghold Web Server's configuration and configure the unsecured server to respond only to Stronghold Web Server. Your httpd.conf might look something like this:

Listen 80
 Listen 443

 ProxyRequests On

 <VirtualHost unsecured.host.com:80>
 ProxyPass / http://117.120.36.10/
 </VirtualHost>

 <VirtualHost unsecured.host.com:443>
 SSLFlag on
 ProxyPass / http://117.120.36.10/
 </VirtualHost>

In this example, all requests for http://unsecured.host.com are routed through port 80, and all requests for https://unsecured.host.com are routed through port 443, the SSL/TLS port. You can hone the configuration further to control which directories clients can access through port 80, and which they can only access through port 443. The nonsecure server should then be configured to accept requests only from Stronghold Web Server.



An SSL/TLS-to-SSL/TLS Proxy

If you are using the proxy server for general proxy services, such as Web access through a firewall, then you have the option to restrict those communications so that only SSL/TLS transactions are supported. Although this ensures security for all transactions, keep in mind that it also prohibits transactions with clients and servers that do not support SSL or TLS.

NOTE: Netscape Navigator and Microsoft Internet Explorer do not support SSL/TLS transactions to proxy servers. Even if all clients on your internal network support SSL/TLS to proxies, they will not have access to servers that do not support SSL/TLS.

To accomplish this, you can enable proxy service only on the SSL/TLS port

<VirtualHost _default_:443>
 ProxyRequests on
 SSLFlag on
 </VirtualHost>




[Top] [Prev] [Next] [Last]
© 1998 C2Net International
Feedback: stronghold-docs@c2.net 		C2Net Logo