![Extracted pic [3]](chapter4.fm-image-3.gif)
Normally, a server fulfils requests by returning files from within its own directory tree. A proxy server fulfils 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 3.0 comes with a caching proxy module, mod_proxy, that supports the HTTP/1.0, HTTPSFTP, and CONNECT protocols. The proxy module is compiled in by default, so is present when the server is installed. Stronghold can be recompiled without mod_proxy if you wish, see See page 8-9.
![Extracted pic [1]](chapter4.fm-image-1.gif)
The 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. The proxy server can be configured to perform secured or unsecured 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:
In order to use Stronghold Web Server 3.0 as a regular proxy, clients must be configured to use the proxy host.
This chapter shows you how configure the proxy and activate caching, then explains how to set up
This configuration passes proxy requests to other proxy servers.
This configuration protects non-SSL clients by converting their HTTP requests to secure HTTPS requests.
Use this configuration to add SSL/TLS security to a nonsecure server that resides on the same platform as the proxy server.
Use this configuration to add SSL/TLS security to a nonsecure server that resides on a separate platform.
This configuration works when both clients and remote servers support SSL or TLS.
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 used to control the proxy server's behaviour should go inside this container. For example, to implement basic authentication for the proxy server, add the following to httpd.conf.
<Directory proxy;*>
AuthType Basic
AuthuserFile <ServrRoot>/proxy/.htpasswd
AuthName Proxy
require valid-user
</Directory>
Under this configuration, only users with valid logins and passwords in the htpaswd 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.c2net/>
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 proxy server functions differently from the regular server, some server 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 the proxy server. In that case, the directives should go inside the proxy host's <virtualHost> container:
<VirtualHost proxy.host.com*>
...
<VirtualHost>
The cache directives, described in more detail in "Proxy Service and Caching" on page 7-48, are as follows:
In order to disable caching, either
ProxyRequests and the cache directives are included in the default configuration file, commented out. To use their default values, simply uncomment them. They can be modified to suit any configuration.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 the 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.
Since the proxy moduleis currently limited to HTTP/1.0, HTTPSFTP, 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 3.0 to contact other proxies for requests it cannot fulfill. Users can then direct all requests to Stronghold Web Server 3.0 . To do this, use the ProxyRemote directive:
ProxyRemote gopher http://www.gopherproxy.net/
ProxyRemote *://www.anything.net http://www.proxy.com/
Sites can be blocked to prevent users from accessing them through the proxy server. The
ProxyBlock directive specifies a space-separated list of hosts, domains, or URL keywords that the proxy server blocks. For example:
ProxyBlock www.a_badsite.com not_allowed.org censored
In this example, the proxy blocks all requests for www.solidoak.com, any host in the not_allowed.org domain, and any URI that includes the string "censored."
This directive can also be used to block access to all sites, like this:
ProxyBlock *
A similar effect can be achieved by setting ProxyRequests to "off."
Proxy service can be configured in a wide variety of ways. The examples in this section illustrate a few simple configurations for common proxy service scenarios:
If the clients on an internal network do not support SSL or TLS, Stronghold Web Server 3.0 can proxy their regular HTTP requests into SSL/TLS. It can also 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.
![Extracted pic [2]](chapter4.fm-image-2.gif)
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>
If you have a Web server that does not support SSL or TLS, you can use Stronghold Web Server 3.0 to perform SSL/TLS transactions on behalf of that 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.
When the two coexist on the same platform, they 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>
If you have a web server that does not support SSL or TLS, you can use Stronghold Web Servre to perform SSL/TLS transactions on behalf of your server. Inorder to ensure reasonable security, the unsecured server must be:
The proxy passes all SSL/TLS requests for those hosts to port 80, then returns the response as an SSL/TLS transaction. You could configure the unsecured server so that the only access to it is through Stronghold Web Server 3.0 doing the SSL/TLS-to-HTTP proxying.
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.
Assuming that the two servers already reside on separate hardware platforms with separate IP address, you must first;
![Extracted pic [4]](chapter4.fm-image-4.gif)
The hostname of the unsecured server can be used as a virtual host in Stronghold Web Server 3.0 's configuration. The unsecured server can then be configured to respond only to Stronghold Web Server 3.0 . The configuration 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 the Stronghold Web Server 3.0 acting as the SSL/TLS-to-HTTP 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 prevents requests from browsers, and to servers that do not support SSL or TLS.
To accomplish this, enable proxy service only on the SSL/TLS port
<VirtualHost _default_:443>
ProxyRequests on
SSLFlag on
</VirtualHost>