# WASD Features and Facilities

# 7.Proxy Services

7.1 HTTP Proxy Serving
7.1.1 Enabling A Proxy Service
7.1.2 Proxy Affinity
7.1.3 Proxy Bind
7.1.4 Proxy Chaining
7.1.5 Controlling Proxy Serving
7.2 Proxy Cache
7.3 CONNECT Serving
7.3.1 Enabling CONNECT Serving
7.3.2 Controlling CONNECT Serving
7.4 SOCKS Version 5
7.5 Gatewaying Using Proxy
7.5.1 Reverse Proxy
7.5.2 Proxy Rework
7.5.3 One-Shot Proxy
7.5.4 DNS Wildcard Proxy
7.5.5 Originating SSL
7.6 Tunneling Using Proxy
7.6.1[ServiceProxyTunnel] CONNECT
7.6.2[ServiceProxyTunnel] RAW
7.6.3[ServiceProxyTunnel] FIREWALL
7.6.4 Encrypted Tunnel
7.6.5 Encrypted Tunnel With Authentication
7.6.6 Shared SSH Tunnel
7.6.7 Complex Private Tunneling
7.6.8 Tunnelling Source

↩︎ | ↖︎ | ↑︎ | ↘︎ | ↪︎

A proxy server acts as an intermediary between Web clients and Web servers. It listens for requests from the clients and forwards these to remote servers. The proxy server then receives the responses from the servers and returns them to the clients. Why go to this trouble? There are several reasons, the most common being:

- To allow internal clients access to the Internet from behind a firewall. Browsers behind the firewall have full Web access via the proxy system.
- To provide controlled access to internal resources for external clients. The proxy server provides a managed gateway through a firewall into an organisation's Web resources.
- Many proxy servers provide caching, or local storage, of responses. For frequent or commonly accessed resources this can not only significantly reduce apparent network latency but also greatly reduce the total traffic downloaded by a site.
- For anonymity. Although often related directly to firewall security considerations, it can also sometimes be an advantage to just not reveal the exact source of Web transactions from within your local network.

##### Proxy Serving Quick-Start

No additional software needs to be installed to provide proxy serving.

Proxy servering is essentially configured using a combination of configuration directives in WASD_CONFIG_GLOBAL and WASD_CONFIG_SERVICE to enable proxy serving both globally and then for allow a specific service to make outgoing connections, along with mapping directives in WASD_CONFIG_MAP to control and direct those outgoing connections.

The following steps provide a brief outline of proxy configuration.

1. Enable proxy serving and specify which particular services are to be proxies (7.1.1 Enabling A Proxy Service and Service Configuration of WASD Configuration)
2. If providing SSL tunneling (proxy of Secure Sockets Layer transactions) add/modify a service for that (7.3 CONNECT Serving).
3. Add WASD_CONFIG_MAP mapping rules for controlling this/these services (7.1.5 Controlling Proxy Serving and 7.3.2 Controlling CONNECT Serving).
4. Restart server (HTTPD/DO=RESTART).

###### Proxy Error Messages

##### Error Messages

When proxy processing is enabled and WASD_CONFIG_GLOBAL directive [ReportBasicOnly] is disabled it is necessary to make adjustments to the contents of the WASD_CONFIG_MSG message configuration file [status] item beginning "Additional Information". Each of the "/httpd/-/statusnxx.html" links

<a href="/httpd/-/status1xx.html">1<i>xx</i></a> <a href="/httpd/-/status2xx.html">2<i>xx</i></a> <a href="/httpd/-/status3xx.html">3<i>xx</i></a> <a href="/httpd/-/status4xx.html">4<i>xx</i></a> <a href="/httpd/-/status5xx.html">5<i>xx</i></a> <a href="/httpd/-/statushelp.html">help</a>
should be changed to include a local host component
<a href="http://local.host.name/httpd/-/status1xx.html">1<i>xx</i></a> <a href="http://local.host.name/httpd/-/status2xx.html">2<i>xx</i></a> <a href="http://local.host.name/httpd/-/status3xx.html">3<i>xx</i></a> <a href="http://local.host.name/httpd/-/status4xx.html">4<i>xx</i></a> <a href="http://local.host.name/httpd/-/status5xx.html">5<i>xx</i></a> <a href="http://local.host.name/httpd/-/statushelp.html">help</a>

If this is not provided the links and any error report will be interpreted by the browser as relative to the server the proxy was attempting to request from and the error explanation will not be accessible.

## 7.1 HTTP Proxy Serving

WASD provides a proxy service for the HTTP scheme (prototcol).

Proxy serving generally relies on DNS resolution of the requested host name. DNS lookup can introduce significant latency to transactions. To help ameliorate this WASD incorporates a host name cache. To ensure cache consistency the contents are regularly flushed, after which host names must use DNS lookup again, refreshing the information in the cache. The period of this cache purge is contolled with the [ProxyHostCachePurgeHours] configuration parameter.

When a request is made by a proxy server is is common for it to add a line to the request header stating that it is a forwarded request and the agent doing the forwarding. With WASD proxying this line would look something like this:

Forwarded: by http://host.name.domain (HTTPd-WASD/8.4.0 OpenVMS/IA64 SSL)
It is enabled using the [ProxyForwarded] configuration parameter.

An additional, and perhaps more widely used facility, is the Squid extension field to the proxied request header supplying the originating client host name or IP address.

X-Forwarded-For: client.host.name
It is enabled using the [ProxyXForwardedFor] configuration parameter.

### 7.1.1 Enabling A Proxy Service

Proxy serving is enabled on a global basis using the WASD_CONFIG_GLOBAL file [ProxyServing] configuration parameter. After that each virtual service must have proxy functionality enabled as a per-service configuration.

WASD can configure services using the WASD_CONFIG_GLOBAL [service] directive, the WASD_CONFIG_SERVICE configuration file, or even the /SERVICE= qualifier.

##### WASD_CONFIG_SERVICE

Using directives listed in Service Configuration of WASD Configuration) this example illustrates configuring a non-proxy server (the disabled is the default and essentially redudant) and a proxy service.

[[http://alpha.example.com:80]] [ServiceProxy] disabled [[http://alpha.example.com:8080]] [ServiceProxy] enabled

### 7.1.2 Proxy Affinity

High performance/highly available proxy server configurations require more than one instance configured and running. Whether this is done by running multiple instances on the same host or one instance on multiple hosts, it leads to situations where successive requests will be processed by different instances. As those instances don't share a common name to IP address cache, they will eventually use different IP addresses when trying to connect to an origin server running on multiple hosts.

This may result in the following, user visible, issues:

- multiple requests for authentication (one from each origin host)
- loss of icons, images, javascripts, CSS because requests for these files, although they return a 401 status, will not trigger a browser authentication dialog
- loss of context and performance issues where scripts/environments need to be started on a new host (php, python, webware,...)

For these reasons, the proxy server will make every effort to relay successive requests from a given client to the same origin host as long as this one is available (built-in failover capability will ultimately trigger the choice of a new host). This is known as client to origin affinity or proxy affinity capability.

Proxy to origin server affinity is enabled using the following service configuration directive.

[[http://alpha.example.com:8080]] [ServiceProxy] enabled [ServiceProxyAffinity] enabled

##### Uses HTTP Cookies

Obviously the use of cookies must be enabled in the browser or this facility will not operate for that client. After the first successful connection to an origin host, the proxy server will send a cookie indicating the IP address used to the client browser. Upon subsequent requests, this cookie will be used to select the same host. The cookie is named WasdProxyAffinity_origin.host.name and the value simply the IP address in dotted decimal. This cookie is not propagated beyond the proxy service but may be WATCHed by checking the Proxy Processing item.

### 7.1.3 Proxy Bind

It is possible to make the outgoing request appear to originate from a particular source address. The Network Interface must be able to bind to the specified IP address (i.e. it cannot be an arbitrary address).

[[http://alpha.example.com:8080]] [ServiceProxy] enabled [ServiceProxyBind] 131.185.250.1

The same behaviour may be accomplished with an WASD_CONFIG_MAP mapping rule.

SET http://*.example.com proxy=bind=131.185.250.1

### 7.1.4 Proxy Chaining

Some sites may already be firewalled and have corporate proxy servers providing Internet access. It is quite possible to use WASD proxying in this environment, where the WASD server makes the proxied requests via the next proxy server in the hierarchy. This is known as proxy chaining.

[[http://alpha.example.com:8080]] [ServiceProxy] enabled [ServiceProxyChain] next.proxy.host

Chaining may also be controlled on a virtual service or path basis using an WASD_CONFIG_MAP mapping rule.

SET http://*.com proxy=chain=next.proxy.host:8080

##### Chain Authorization

If the upstream proxy server requires authorization this may be supplied using a per-service directive

[[http://alpha.example.com:8080]] [ServiceProxy] enabled [ServiceProxyChain] next.proxy.host [ServiceProxyChainCred] basic:username>:<password>
or via mapping rule
SET http://*.com proxy=chain=next.proxy.host:8080 \ proxy=chain=cred=basic:<username>:<password>

The basic: keyword allows WASD to appropriately encode the credentials. Basic authentication is the only scheme currently supported.

### 7.1.5 Controlling Proxy Serving

Requests at a service enabled for proxy processing are directed to proxy processing using a fundamental rule which terminates rule processing and initiates the outgoing connection.

pass * http://
This rule and variant equivalents for CONNECT processing, and in combination with other rules to purpose, are seen in the examples in this section on proxy.

Controlling both access-to and access-via proxy serving is possible.

##### Proxy Password

Access to the proxy service can be directly controlled through the use of WASD authorization. Proxy authorization is distinct from general access authorization. It uses specific proxy authorization fields provided by HTTP, and by this allows a proxied transaction to also supply transaction authorization for the remote server. In the WASD_CONFIG_SERVICE configuration file.

[[http://alpha.example.com:8080]] [ServiceProxy] enabled [ServiceProxyAuth] proxy

In addition to the service being specified as requiring authorization it is also necessary to configure the source of the authentication. This is done using the WASD_CONFIG_AUTH configuration file. The following example shows all requests for the proxy virtual service must be authorized (GET and well as POST, etc.), although it is possible to restrict access to only read (GET), preventing data being sent out via the server.

[[alpha.example.com:8080]] ["Proxy Access"=PROXY_ACCESS=id] http://* read+write

##### Chain Password

An up-stream, chained proxy server (7.1.4 Proxy Chaining) may be permitted to receive proxy authentication from the client via a WASD proxy server using the CHAIN keyword. Unconfigured, WASD does not propagate HTTP proxy authorization fields. Only one proxy server in a chain can be authenticated against.

[[http://alpha.example.com:8080]] [ServiceProxy] enabled [ServiceProxyAuth] chain

##### Local Password

It is also possible to control proxy access via local authorization, although this is less flexible by removing the ability to then pass authorization information to the remote service. In other repects it is set up in the same way as proxy authorization, but enabled using the LOCAL keyword.

[[http://alpha.example.com:8080]] [ServiceProxy] enabled [ServiceProxyAuth] local

##### Access Filtering

Extensive control of how, by whom and what a proxy service is used for may be exercised using WASD general and conditional mapping Request Processing Configuration of WASD Configuration) and Conditional Mapping of WASD Configuration) possibly in the context of a virtual service specification for the particular connect service host and port (see Virtual Servers of WASD Configuration). The following examples provide a small indication of how mapping could be used in a proxy service context.

1. It is possible, though more often not practical, to regulate which hosts are connected to via the proxy service. For example, the following rule forbids accessing any site with the string "hacker" in it (for the proxy service "alpha…:8080".
   [[alpha.example.com:8080]] pass http://*hacker*/* "403 Proxy access to this host is forbidden." pass http://*
2. Or as in the following example, only allow access to specific sites.
   [[alpha.example.com:8080]] pass http://*.org/* pass http://*.digital.com/* pass http://* "403 Proxy access to this host is forbidden."
3. It is also possible to restrict access via the proxy service to selected hosts on the internal subnet. Here only a range of literal addresses plus a single host in another subnet are allowed access to the service.
   [[alpha.example.com:8080]] pass http://* "403 Restricted access." ![ho:131.185.250.* ho:131.185.200.10] pass http://*
4. In the following example POSTing to a particular proxied servers is not allowed (why I can't imagine, but hey, this is an example!)
   [[alpha.example.com:8080]] pass http://subscribe.sexy.com/* "403 POSTing not allowed." [me:POST] pass http://*
5. It is possible to redirect proxied requests to other sites.
   [[alpha.example.com:8080]] redirect http://www.sexy.com/* http://www.disney.com/ pass http://*
6. A proxy service is just a specialized capability of a general HTTP service. Therefore it is quite in order for the one service to respond to standard HTTP requests as well as proxy-format HTTP requests. To enforce the use of a particular service as proxy-only, add a final rule to a virtual service's mapping restricting non-proxy requests.
   [[alpha.example.com:8080]] pass http://* pass /* "403 This is a proxy-only service."
7. This example provides the essentials when supporting reverse proxying. Note that mappings may become quite complex when supporting access to resources across multiple internal systems (e.g. access to directory icons).
   [[main.corporate.server.com:80]] pass /sales/* http://sales.corporate.server.com/* pass /shipping/* http://shipping.corporate.server.com/* pass /support/* http://support.corporate.server.com/* pass * "403 Nothing to access here!"

##### Note

To expedite proxy mapping is it recommended to have a final rule for the proxy virtual service that explicitly passes the request. This would most commonly be a permissive pass as in example 1, could quite easily be an restrictive pass as in example 2, or a combination as in example 6.

##### Request Modification

Using path mapping rules (see Request Processing Configuration of WASD Configuration). it is possible to remove or specifically set selected proxied request headers. Many headers are critical to server processing but some are informational or otherwise amenable to change. This can be undertaken using the SET mapping rule proxy=header=<parameter>.

For example, to have a proxy service suppress the "Referer:" request header:

# WASD_CONFIG_MAP set * proxy=header=referer

To modify the "Referer:" request header to a fixed URL:

set * proxy=header=referer=https://whatever/

To modify the "User-Agent:" request header to a specific string:

set * "proxy=header=user-agent=None of your business!"

## 7.2 Proxy Cache

###### Proxy Cache is OBSOLETE

Caching involves using the local file-system for storage of responses that can be reused when a request for the same URL is made.

##### As of WASD v12.0 Caching is OBSOLETE

With the overwhelming Internet move to encrypted everything, the usefulness of a proxy server local cache for cleartext responses is marginal at best. Related configuration directives are reported obsolete and ignored.

## 7.3 CONNECT Serving

The connect service provides firewall proxying for any connection-oriented TCP/IP access. Essentially it provides the ability to tunnel any other protocol via a Web proxy server. In the context of Web services it is most commonly used to provide firewall-transparent access for Secure Sockets Layer (SSL) transactions. It is a special case of the more general tunneling provided by WASD, see 7.6 Tunneling Using Proxy.

### 7.3.1 Enabling CONNECT Serving

As with proxy serving in general, CONNECT serving may enabled on a per-service basis using the WASD_CONFIG_GLOBAL [service] directive, the WASD_CONFIG_SERVICE configuration file, or even the /SERVICE= qualifier.

The actual services providing the CONNECT access (i.e. the host and port) are specified on a per-service basis. This means it is possible to have CONNECT and non-CONNECT services deployed on the one server, as part of a general proxy service or standalone. CONNECT proxying is enabled by appending the connect keyword to the particular service specification. The following example shows a non-proxy and proxy services, with and without additional connect processing enabled.

[[http://alpha.example.com:80]] [[http://alpha.example.com:8080]] [ServiceProxy] enabled [[http://alpha.example.com:8081]] [ServiceProxyTunnel] connect [[http://alpha.example.com:8082]] [ServiceProxy] enabled [ServiceProxyTunnel] connect

### 7.3.2 Controlling CONNECT Serving

The connect service poses a significant security dilemma when in use in a firewalled environment. Once a CONNECT service connection has been accepted and established it essentially acts as a relay to whatever data is passed through it. Therefore any transaction whatsoever can occur via the connect service, which in many environments may be considered undesirable.

In the context of the Web and the use of the connect service for proxying SSL transactions it may be well considered to restrict possible connections to the well-known SSL port, 443. This may be done using conditional directives, as in the following example:

[[alpha.example.com:8080]] if (request-method:CONNECT) pass *:443 pass * "403 CONNECT only allowed to port 443." endif
All of the comments on the use of general and conditional mapping made in 7.1.5 Controlling Proxy Serving can also be applied to the connect service.

## 7.4 SOCKS Version 5

SOCKS is an Internet protocol that exchanges network packets between a client and server through a proxy server. SOCKS5 optionally provides authentication so only authorized users may access a server. Practically, a SOCKS server proxies TCP connections to an arbitrary IP address.

WASD SOCKS5 supports only CONNECT TCP/IP and not BIND or UDP-associate.

##### Enabling SOCKS5 Proxy

A SOCK5 proxy connection must be mapped using the socks5:// pseudo scheme. The following rule allows connection to any host name or address.

[[alpha.example.com:8080]] pass socks5://*
To selectively allow SOCKS5 access then map to a specific host name or address, and optional port.
[[alpha.example.com:8080]] pass socks5://the.host.name pass socks5://134.142.71.8 pass socks5://137.146.74.10:22

## 7.5 Gatewaying Using Proxy

WASD is fully capable of mapping non-proxy into proxy requests, with various limitations on effectiveness considering the nature of what is being performed.

Gatewaying between request schemes (protocols)

- HTTP to HTTP (a gateway of sorts - standard proxy)
- HTTP TO HTTP-over-SSL (non-secure to secure)
- HTTP to FTP
- HTTP-over-SSL to HTTP (secure to non-secure)
- HTTP-over-SSL to HTTP-over-SSL (secure to secure)
- HTTP-over-SSL to FTP

and also gatewaying between IP versions

- IPv4 to IPv6
- IPv6 to IPv4

All can be useful for various reasons. One example might be where a script is required to obtain a resource from a secure server via SSL. The script can either be made SSL-aware, sometimes a not insignificant undertaking, or it can use standard HTTP to the proxy and have that access the required server via SSL. Another example might be accessing an internal HTTP resource from an external browser securely, with SSL being used from the browser to the proxy server, which the accesses the internal HTTP resource on its behalf.

##### Request Redirect

The basic mechanism allowing this gatewaying is "internal" redirection. The redirect mapping rule (see REDIRECT Rule of WASD Configuration) either returns the new URL to the originating client (requiring it to reinitiate the request) or begins reprocessing the request internally (transparently to the client). It is this latter function that is obviously used for gatewaying.

### 7.5.1 Reverse Proxy

The use of WASD proxy serving as a firewall component assumes two configured network interfaces on the system, one of which is connected to the internal network, the other to the external network. (Firewalling could also be accomplished using a single network interface with router blocking external access to all but the server system.) Outgoing (internal to external) proxying is the most common configuration, however a proxy server can also be used to provide controlled external access to selected internal resources. This is sometimes known as reverse proxy and is a specific example of WASD's general non-proxy to proxy request redirection capability (7.5 Gatewaying Using Proxy).

In this configuration the proxy server is contacted by an external browser with a standard HTTP request. Proxy server rules map this request onto a proxy-request format result. For example:

redirect /sales/* /http://sales.server.com/*?

Note that the trailing question-mark is required to propagate any query string (see REDIRECT Rule of WASD Configuration).

The server recognises the result format and performs a proxy request to a system on the internal network. Note that the mappings required could become quite complex, but it is possible. See example 7 in 7.1.5 Controlling Proxy Serving.

##### Redirection Location Field

If a reverse proxied server returns a redirection response (302) containing a "Location: url" field with the host component the same reverse-proxied-to server it can be rewritten to instead contain the proxy server host. If these do not match the rewrite does not occur. Using the redirection example above, the SET mapping rule proxy=reverse=location specifies the path that will be prefixed to the path component in the location field URL. Usually this would be the same path used to map the reverse proxy redirect (in this example "/sales/"), though could be any string (presumably detected and processed by some other part of the mapping).

set /sales/* proxy=reverse=location=/sales/ redirect /sales/* /http://sales.server.com/*?
This could be simplified a little by using a postfix SET rule along with the original redirect.
redirect /sales/* /http://sales.server.com/*? proxy=reverse=location=/sales/

If the proxy=reverse=location=<string> ends in an asterisk the entire 302 location field URL is appended (rather than just the path) resulting in something along the lines of

Location: http://proxy.server.com/sales/http://sales.server.com/path/
which once redirected by the client can be subsequently tested for and some action made by the proxy server according to the content (just a bell or whistle ;-).

##### Authorization Verification

WASD can authorize reverse proxy requests locally (perhaps from the SYSUAF) and rewrite that username into the proxied requests "Authorization: …" field. The proxied-to server can then verify that the request originated from the proxy server and extract and use that username as authenticated.

This functionality is described in the WASD_ROOT:[SRC.HTTPD]PROXYVERIFY.C module.

### 7.5.2 Proxy Rework

The proxy rework facility will modify a target string to a replacement string in the request header (e.g. Host:), the response header (e.g. set-cookie:), and in the response body. Rework will be applied to HTML and CSS responses.

These are simple string matches.

Proxy rework must be enabled for a service by setting a maximum size for the HTML response body to be reworked, in kB.

# WASD_CONFIG_SERVICE [[*.1924]] [ServiceReworkMax] 128
Specific paths must then be SET in WASD_CONFIG_MAP to have proxy requests reworked.
# WASD_CONFIG_MAP [[*:1924]] set * proxy=rework=192.168.1.3=192.168.1.2

##### Note

Proxy rework likely needs a lot more work!

Also consider the ‘proxyMUNGE Utility’ in 7.5.2 Proxy Rework below.

##### proxyMUNGE Utility

This utility (CGIplus script) can be used to rewrite HTTP response "Location:" fields, "Set-Cookie:" path and domain components and URLs in HTML and CSS content.

This functionality is described in the prologue to the code WASD_ROOT:[SRC.UTILS]PROXYMUNGE.C

##### Note

The proxyMUNGE Utility handles all response rewriting and so when employing it to perform reverse-proxy processing it is unnecessary to use the proxy=reverse=location=<string> mapping rule described in ‘Redirection Location Field’ in 7.5.1 Reverse Proxy.

### 7.5.3 One-Shot Proxy

This looks a little like reverse proxy, providing access to a non-local resource via a standard (non-proxy) request. The difference allows the client to determine which remote resource is accessed. This works quite effectively for non-HTML resources (e.g. image, binary files, etc.) but non-self-referential links in HTML documents will generally be inaccessible to the client. This can provide provide scripts access to protocols they do not support, as with HTTP to FTP, HTTP to HTTP-over-SSL, etc.

Mappings appropriate to the protocols to be support must be made against the proxy service. Of course mapping rules may also be used to control whom or to what is connected.

[[the.proxy.service:port]] # support "one-shot" non-proxy to proxy redirect redirect /http://* http://* redirect /https://* https://* redirect /ftp://* ftp://* # OK to process these (already, or now) proxy format requests pass http://* http://* pass https://* https://* pass ftp://* ftp://*

The client may the provide the desired URL as the path of the request to the proxy service. Notice that the scheme provided in the desired URL can be any supported by the service and its mappings.

http://the.proxy.service:port/http://the.remote.host/path http://the.proxy.service:port/https://the.remote.host/path http://the.proxy.service:port/ftp://the.remote.host/pub/

### 7.5.4 DNS Wildcard Proxy

This relies on being able to manipulate host record in the DNS or local name resolution database. If a "*.the.proxy.host" DNS (CNAME) record is resolved it allows any host name ending in ".the.proxy.host" to be resolved to the corresponding IP address. Similarly (at least the Compaq TCP/IP Services) the local host database allows an alias like "another.host.name.proxy.host.name" for the proxy host name. Both of these would allow a browser to access "another.host.name.proxy.host.name" with it resolved to the proxy service. The request "Host:" field would contain "another.host.name.proxy.host.name".

Using this approach a fully functioning proxy may be implemented for the browser without actually configuring it for proxy access, where returned HTML documents contain links that are always correct with reference to the host used to request them. This allows the client an ad hoc proxy for selected requests. For a wildcard (CNAME) record the browser user may enter any host name prepended to the proxy service host name and port and have the request proxied to that host name. Entering the following URL into the browser location field

http://the.host.name.the.proxy.service:8080/path
would result in a standard HTTP proxy request for "/path" being made to "the.host.name:80". With the URL
https://the.host.name.the.proxy.service:8443/path
an SSL proxy request. Note that normally the well-known port would be used to connect to (80 for http: and 443 for https:). If the final, period-separated component of the wildcard host name is all digits it is interpreted as a specific port to connect to. The example
http://the.host.name.8001.the.proxy.service:8080/path
would connect to "the.host.name:8001", and
https://the.host.name.8443.the.proxy.service:8443/path
to "the.host.name:8443".

##### Note

It has been observed that some browsers insist that an all-digit host name element is a port number despite it being prefixed by a period not a colon. These browsers then attempt to contact the host/port directly. This obviously precludes using an all-digit element to indicate a target port number with these browsers.

This wildcard DNS entry approach is a more fully functional analogue to common proxy behaviour but is slightly less flexible in providing gatewaying between protocols and does require more care in configuration. It also relies on the contents of the request "Host:" field to provide mapping information (which generally is not a problem with modern browsers). The mappings must be performed in two parts, the first to handle the wildcard DNS entry, the second is the fairly standard rule(s) providing access for proxy processing.

[[the.proxy.service:port1]] if (host:*.the.proxy.service:port1) redirect * /http://* else pass http://* http://* endif

The obvious difference between this and one-shot proxy is the desired host name is provided as part of the URL host, not part of the request path. This allows the browser to correctly resolve HTML links etc. It is less flexible because a different proxy service needs to be provided for each protocol mapping. Therefore, to allow HTTP to HTTP-over-SSL proxy gatewaying another service and mapping would be required.

[[the.proxy.service:port2]] if (host:*.the.proxy.service:port2) redirect * /https://* else pass https://* https://* endif

### 7.5.5 Originating SSL

This proxy function allows standard HTTP clients to connect to Secure Sockets Layer (4. Transport Layer Security) services. This is very different to the CONNECT service (7.3 CONNECT Serving), allowing scripts and standard character-cell browsers supporting only HTTP to access secure services.

Standard username/password authentication is supported (as are all other standard HTTP request/response interactions). The use of X.509 client certificates (4.5.12 Authorization Using X.509 Certification) to establish outgoing identity is not currently supported.

##### Enabling SSL

Unlike HTTP and FTP proxy it requires the service to be specifically configured using the [ServiceClientSSL] directive.

There are a number of Secure Sockets Layer related service parameters that should also be considered (see Service Configuration of WASD Configuration). Although most have workable defaults unless [ServiceProxyClientSSLverifyCA] and [ServiceProxyClientSSLverifyCAfile] are specifically set the outgoing connection will be established without any checking of the remote server's certificate. This means the host's secure service could be considered unworthy of trust as the credentials have not been established.

[[http://alpha.example.com:8080]] [ServiceProxy] enabled [ServiceClientSSL] enabled

## 7.6 Tunneling Using Proxy

WASD supports the CONNECT method which effectively allows tunneling of raw octets through the proxy server. This facility is most commonly used to allow secure SSL connections to be established with hosts on the 'other side' of the proxy server. This basic mechanism is also used by WASD to provide an extended range of tunneling services. The term raw is used here to indicate an 8 bit, bidirectional, asynchronous exchange of octets between two entities, as a protocol family, not necessarily as an application (but can be so). Global proxy serving must be enabled (7.1.1 Enabling A Proxy Service) and then each service must be configured and mapped according to the desired mode of tunneling. Disabling or setting timeouts appropriately on the mapped service is important if connections are not to be disrupted by general server timeouts on output and non-progress (quiescent connections).

### 7.6.1[ServiceProxyTunnel] CONNECT

A service with this configuration is used as a target for CONNECT proxying (usually SSL through a firewall). The client expects an HTTP success (200) response once the remote connection is established, and HTTP error response if there is a problem, and once established just relays RAW octets through the proxy server (classic CONNECT behaviour).

# WASD_CONFIG_SERVICE [[http://*:8080]] [ServiceProxy] enabled [ServiceProxyTunnel] connect
# WASD_CONFIG_MAP [[*:8080]] if (request-method:connect) pass *:443 *:443 pass * "403 CONNECT only allowed to port 443." endif

This configuration enables CONNECT processing and limits any connect to SSL tunneling (i.e. port 443 on the remote system).

### 7.6.2[ServiceProxyTunnel] RAW

This allows any raw octet client (e.g. telnet) to connect to the port and by mapping be tunnelled to another host and port to connect to its service (e.g. a telnet service). The usual HTTP responses associated with CONNECT processing are not provided.

# WASD_CONFIG_SERVICE [[http://*:10023]] [ServiceProxy] enabled [ServiceProxyTunnel] raw
# WASD_CONFIG_MAP [[*:10023]] if (request-method:connect) pass *:0 raw://another.host:23 timeout=none,none,none endif pass "403"

Telnet is used in the example above but the principle equally applies to any protocol that uses a raw 8 bit, bidirectional, asynchronous exchange of octets. Another example might be an SMTP service (port 25).

##### SSL to RAW

Using a tunnel it is possible to put a TLS/SSL (https://) front-end service to an otherwise plaintext-only service (http://).

# WASD_CONFIG_SERVICE [[https://tls-host:443]] [ServiceNonSSLRedirect] https://tls.host:443 [ServiceProxy] enabled [ServiceProxyTunnel] raw
# WASD_CONFIG_MAP [[*:443]] if (request-method:connect) pass *:0 raw://non-tls.host:80 endif pass "403"

##### Chaining RAW

It is possible to have a raw tunnel establish itself through a proxy chain (7.1.4 Proxy Chaining) by transparently generating an intermediate CONNECT request to the up-stream proxy server. Note that not all CONNECT proxy will allow connection to just any specified port. For security reasons it it is quite common to restrict CONNECT to port 443.

# WASD_CONFIG_SERVICE [[http://*:10025]] [ServiceProxy] enabled [ServiceProxyTunnel] raw
# WASD_CONFIG_MAP [[*:10025]] if (request-method:connect) pass *:0 raw://another.host:25 proxy=chain=proxy.host:8080 endif pass "403"

Any error in connecting to the chained proxy, making the request, connecting to the destination, etc. (i.e. any error at all) is not reported. The network connection is just dropped. Use WATCH to establish the cause if necessary.

### 7.6.3[ServiceProxyTunnel] FIREWALL

With this configuration a service expects that the first line of text from the client contains a host name (or IP address) and optional port (e.g. "the.host.name" or "the.host.name:23"). This allows a variable destination to be mapped. The usual HTTP responses associated with CONNECT processing are not provided.

# WASD_CONFIG_SERVICE [[http://*:10023]] [ServiceProxy] enabled [ServiceProxyTunnel] FIREWALL
# WASD_CONFIG_MAP [[*:10023]] if (request-method:connect) pass *:* raw://*:23 timeout=none,none,none pass * raw://*:23 timeout=none,none,none endif pass "403"

The pass rules force the supplied domain name (and optional port) to be mapped to the telnet port (23). Of course the mapping rules could allow the supplied port to be mapped into the destination if desired.

##### Chaining FIREWALL

As with [ServiceProxyTunnel] RAW it is possible to chain FIREWALL services to an up-stream proxy server. See ‘Chaining RAW’ in 7.6.2 [ServiceProxyTunnel] RAW.

### 7.6.4 Encrypted Tunnel

Up to this point the tunnels have merely been through the proxy server. It is possible to establish and maintain ENCRYPTED TUNNELS between WASD servers. SSL is used for this purpose. This is slightly more complex as both ends of the tunnel need to be configured.

┌────────────┐ ┌────────────┐
◄──unencrypted──◄│ WASD proxy │◄──ENCRYPTED──◄│ WASD proxy │◄──unencrypted──◄
└────────────┘ └────────────┘

This arrangement may be used for any stream-oriented, network protocol between two WASD systems. As it uses standard CONNECT requests (over SSL) it MAY also be possible to be configured between WASD and non-WASD servers.

The following example is going to maintain an encrypted tunnel between WASD servers running on systems KLAATU and GORT. It is designed to allow a user on KLAATU to connect to a specified port using a telnet client, and have a telnet session created on GORT, tunnelled between the two systems via an SSL encrypted connection.

Source of tunnel:

# KLAATU WASD_CONFIG_SERVICE [[http://*:10023]] [ServiceProxy] enabled [ServiceClientSSL] ENABLED [ServiceProxyTunnel] RAW
# KLAATU WASD_CONFIG_MAP [[*:10023]] # if the client is on the local subnet if (remote-addr:192.168.0.0/24 && request-method:connect) pass *:0 https://gort.domain:10443 timeout=none,none,none endif pass "403"

Destination of tunnel:

# GORT WASD_CONFIG_SERVICE [[https://*:10443]] [ServiceProxy] enabled [ServiceProxyTunnel] CONNECT
# GORT WASD_CONFIG_MAP [[*:10443]] # limit the connection to a specific host if (remote-addr:192.168.0.10 && request-method:connect) pass *:0 raw://gort.domain:23 timeout=none,none,none endif pass "403"

When a client connects to the service provided by port 10023 on system KLAATU the connection is immediately processed using a pseudo CONNECT request header. The service on this port is a proxy allowed to initiate SSL connections (client SSL). This service is mapped to system GORT port 10443, an SSL service that allows the CONNECT method (tunneling). KLAATU's proxy initiates an SSL connection with GORT. When established and the CONNECT request from KLAATU is received, it is mapped via a raw tunnel (8 bit, etc.) to its own system port 23 (the telnet service). Telnet is in use at both ends while encrypted by SSL inbetween! Note the use of network addresses and general fail rules used to control access to this service, as well as the disabling of timers that might otherwise shutdown the tunnel.

### 7.6.5 Encrypted Tunnel With Authentication

This arrangement is essentially a variation on example 4. It provides a cryptographic authentication of the originator (source) of the tunnel.

Source of tunnel:

# KLAATU WASD_CONFIG_SERVICE [[http://*:10023]] [ServiceProxy] enabled [ServiceClientSSL] enabled [ServiceProxyTunnel] RAW [ServiceClientSSLcert] WASD_ROOT:[LOCAL]HTTPD.PEM
# KLAATU WASD_CONFIG_MAP [[*:10023]] # if the client is on the local subnet if (remote-addr:192.168.0.0/24 && request-method:connect) pass *:0 https://gort.domain:10443 timeout=none,none,none endif pass "403"

Destination of tunnel:

# GORT WASD_CONFIG_SERVICE [[https://*:10443]] [ServiceProxy] enabled [ServiceProxyTunnel] CONNECT [ServiceProxyAuth] PROXY
# GORT WASD_CONFIG_MAP [[*:10443]] # we'll be relying on X509 authentication if (request-method:connect) pass *:0 raw://gort.domain:23 timeout=none,none,none endif pass "403"
# GORT WASD_CONFIG_AUTH [[*:10443]] [X509] * r+w,param="[VF:OPTIONAL]",~4EAB3CBC735F8C7977EBB41D45737E37

This works by configuring the destination service to insist on proxy authorization. The authorization realm is X509 which causes the destination to demand a certificate from the source (4.5.12 Authorization Using X.509 Certification). The fingerprint of this certificate is checked against the authorization rule before the connection is a allowed to procede.

### 7.6.6 Shared SSH Tunnel

The objective of this raw tunnel variant (see 7.6.2 [ServiceProxyTunnel] RAW) is to allow tunneling of Secure Shell (SSH) via a client site proxy server CONNECT which is usually confined to port 443. Of course most Web servers are configured to provide SSL HTTP on port 443. Sharing of HTTP and SSH on the same port is a little problematic and involves some protocol detection. The following explanation of how it is implemented is so that the reader can understand the requirement for the "timeout quirk".

On configured services; WASD peeks at the incoming TCP byte stream to see if it's SSH protocol. If it is, the socket is associated with a proxy raw tunneling service and proxy tunneling initiated to a mapped SSH server. However (just to make it interesting) some SSH clients do not initiate their own exchange until after the SSH server, and so peeking only works for a subset of clients. Of course this is a Catch-22 of sorts! To provide for these clients; if an input timeout should occur (an SSH client waiting) WASD sets up the tunnel anyway and begins the proxy. The proxied SSH server should then initiate the protocol and the client respond. The directive [ServiceShareSSH] configured to be non-zero both enables this facility for a service and sets the input timeout period (which perhaps should be shorter than the default 30 seconds because such clients will wait that long for any SSH server response).

This approach seems to work well-enough in practice, although users need to be aware that some clients will pause (for the duration of the timeout period – the "timeout quirk") during initial connection setup.

# WASD_CONFIG_SERVICE [[https://*:443] [ServiceShareSSH] 10 [[http://*:10022]] [ServiceProxy] enabled [ServiceProxyTunnel] raw
# WASD_CONFIG_MAP [[*:443] if (request-method:ssh) pass * raw://ssh.server.host:22 \ service=the.proxy.host:10022 \ timeout=none,none,none endif [[*:10022]] pass "403"

This example shows an SSL service, the desired SSH service (which can be local or remote) and the internal proxy service that will provide the connection.

### 7.6.7 Complex Private Tunneling

When creating raw tunnels between WASD servers, and possibly in other circumstances, it is often useful to be able to signal tunnel purpose to the remote end. In this way a single destination port can support multiple tunneling purposes simply through mapping rules. An originating end can inject an HTTP request line, or full request, into the established tunnel connection, which can then be processed by the usual WASD request mapping, and from that alternate services provided based on the intent signalled by the originating end.

This somewhat complex but instructive example illustrates the potential utility and versatility of WASD tunneling. It involves an originating WASD server, a destination (service providing) WASD server, and just to make it interesting an intermediate chained HTTP proxy server (not WASD). The idea is to provide access to various application services not necessarily supported by intermediate HTTP proxies and/or gateways. Four services will be supported by the example; SSH, NNTP IMAP and SMTP.

inside firewall outside
┌────────────┐ ┌─────────────┐ ┌────────────┐
◄──raw──◄│ WASD proxy │◄──ENCRYPTED──◄│ other proxy │◄──ENCRYPTED──◄│ WASD proxy │◄──raw──◄
└────────────┘ └─────────────┘ └────────────┘
wasd.internal.net proxy.internal.net wasd.external.net
proxy.external.net
SSH───8022──┐ ╎ ╎ ┌────22───SSH
SMTP───8025──┼────────────────────────────┤╌╌╌╌┤─────────────────────────────┼────25───SMTP
NNTP───8119──┤ ╎╌╌╌╌╎ ├───119───NNTP
IMAP───8143──┘ ╎ ╎ └───143───IMAP

##### Internal Services

These are the services assigned on the WASD server on the inside of the proxy/gateway. Note that there is one per application to be tunneled. For simplicity each service port number has been selected to parallel the well-known application port number. Note that proxy is enabled on each (allowing them to initiate outgoing connections) and each has SSL enabled (further allowing them to initiate encrypted connections).

# client SSH [[http://*:8022]] [ServiceProxy] enabled [ServiceProxyTunnel] RAW [ServiceClientSSL] enabled # client SMTP [[http://*:8025]] [ServiceProxy] enabled [ServiceProxyTunnel] RAW [ServiceClientSSL] enabled # client IMAP [[http://*:8143]] [ServiceProxy] enabled [ServiceProxyTunnel] RAW [ServiceClientSSL] enabled # client NNTP [[http://*:8119]] [ServiceProxy] enabled [ServiceProxyTunnel] RAW [ServiceClientSSL] enabled

Each client application (i.e. IMAP, SSH) must be configured to connect to its corresponding service port (e.g. IMAP to 8143, SMTP to 8025).

##### Internal Mapping

These mappings are made on the WASD server on the inside of the proxy/gateway. The rules essentially initiate an outgoing encrypted (SSL) connection to the host wasd.external.net supporting the external WASD proxy server. Each is also configured not to connect directly but to request the chained proxy server proxy.internal.net to establish the connection on their behalf.

!##### SSH ##### [[*:8022]] pass * https://wasd.external.net:443 notimeout \ proxy=tunnel=request="CONNECT wasd-ssh" \ proxy=chain=proxy.internal.net:8080 !##### SMTP ##### [[*:8025]] pass * https://wasd.external.net:443 \ proxy=tunnel=request="CONNECT external-smtp" \ proxy=chain=proxy.internal.net:8080 !##### NNTP ##### [[*:8119]] pass * https://wasd.external.net:443 \ proxy=tunnel=request="CONNECT external-nntp" \ proxy=chain=proxy.internal.net:8080 !##### IMAP ##### [[*:8143]] pass * https://wasd.external.net:443 \ proxy=tunnel=request="CONNECT external-imap" \ proxy=chain=proxy.internal.net:8080

If the up-stream proxy server successfully connects to wasd.external.net port 443 the proxy server allows the byte-stream to be asynchonously and bidirectionally exchanged with the internal WASD server outgoing connection. This internal WASD server has initiated an SSL connection and the external server port 443 expects SSL so they can now both negotiate an SSL-encrypted channel essentially directly with each other.

##### External Services

The external WASD service configuration is very simple, a single SSL port.

# general SSL service [[https://wasd.external.net:443]] # outgoing proxy/tunnel service [[http://wasd.external.net:1234]] [ServiceProxy] enabled [ServiceProxyTunnel] raw [ServiceClientSSL] ENABLED

Connections to the 443 port are expected to undertake an SSL negotiation to establish an encrypted channel. This includes incoming tunnel connections. The service on port 1234 is required to support the connections outgoing from the external WASD server to the application server ports.

##### External Mapping

These mappings are all applied to requests at port 443 on the external WASD server wasd.external.net. Each rule checks three request characterstics. First, the request method, "CONNECT". Second, the request URI, varies according to the request. These are the request data injected by the internal WASD server wasd.internal.net using the set=proxy=tunnel=request= mapping rule on the outgoing connection. Third, the originating host (proxy.external.net) address adds an extra filter on from where this facility may be used. The respective pass of the matching rule then initiates an outgoing connection to the respective application server's well-known port. A timeout is applied to limit connection times.

!# SSH tunneling [[*:443]] if (request-method:CONNECT && \ request-uri:"wasd-ssh" && \ remote-addr:205.3.*) \ pass * raw://wasd.external.net:22 service=*:1234 timeout=noprogress=00:00:50 !# SMTP tunneling [[*:443]] if (request-method:CONNECT && \ request-uri:"external-smtp" && \ remote-addr:205.3.*) \ pass * raw://smtp.isp.net:25 service=*:1234 timeout=noprogress=00:00:50 !# NNTP tunneling [[*:443]] if (request-method:CONNECT && \ request-uri:"external-nntp" && \ remote-addr:205.3.*) \ pass * raw://news.isp.net:119 service=*:1234 timeout=noprogress=00:00:* !# IMAP tunneling [[*:443]] if (request-method:CONNECT && \ request-uri:"external-imap" && \ remote-addr:205.3.*) \ pass * raw://imap.isp.net:143 service=*:1234 timeout=noprogress=00:00:50 !# disable general 1234 service usage [[*:1234]] pass * 403 "Internal use only!"

##### Example In Action

Now let's look at an actual example usage. Consider the internal user's IMAP application, say Thunderbird, is configured to use an IMAP server at host wasd.internal.net port 8143. The internal user activates Thunderbird which then intiates an TCP/IP connection to the configured IMAP server expecting to commence the IMAP application protocol.

This connection arrives at wasd.internal.net port 8143 which has a WASD raw tunnel service listening. The connection is accepted and request processing commences. Mapping rules applied to port 8143 initiate an SSL connection to host wasd.external.net which is not directly accessable because of the firewall and must be connected to using the HTTP proxy server proxy.internal.net as an intermediary. This is specified in the same mapping rule. The mapping rule also injects an HTTP request header providing request characteristics that can be identified and acted upon by the external server.

The internal WASD server initiates a connection to the proxy server proxy.internal.net acting as part of the firewall. As it is endeavouring to initiate an SSL connection with the external wasd.external.net host this proxy connection uses a CONNECT request specifying wasd.external.net port 443. The proxy server establishes a connection with the host wasd.external.net at port 443. Once the connection is established it becomes an asynchronous, bidirectional channel between wasd.internal.net and wasd.external.net with the proxy server as a conduit.

The service connection just established is expecting an SSL negotiation in an attempt to establish an encrypted channel. When this negotiation concludes successfully the communications between wasd.internal.net and wasd.external.net become opaque to all external listeners including proxy.internal.net.

The encrypted connection now established, the request begins to be processed by the WASD server at wasd.external.net. A number of mapping rules apply to port 443. Each rule compares the injected request method and URI until, in this case, the external-imap rule matches. This rule specifies that a raw connection be established with the host imap.isp.net at port 143 using the proxy-capable port 1234 service. A timeout limits the duration this connection can be held unused.

The IMAP application server at imap.isp.external port 143 accepts the connection at begins to communicate using the IMAP protocol.

There is now a raw (8 bit, asynchronous, bidirectional) connection from the Thunderbird client to wasd.internal.net, (encrypted) through to proxy.internal.net, (encrypted) through to wasd.external.net, and raw to the IMAP server at imap.isp.net. This raw connection will be used for communication between Thunderbird and the IMAP server using the IMAP application protocol.

### 7.6.8 Tunnelling Source

When a tunnel is established into a system the source of that connection (IP host-name/address and port) becomes obscured. By setting the path to the destination port proxy=forwarded=for (host name) or proxy=forwarded=address (IP address) the external client can be obtained using data contained in the logical name WASD_TUNNEL.

Consider tunneling external port 22345 to internal port 22 - Secure Shell.

# WASD_CONFIG_SERVICE [[http://*:22345]] [ServiceProxy] enabled [ServiceProxyTunnel] RAW # WASD_CONFIG_MAP [[*:22345]] pass * raw://localhost:22 notimeout

To Secure Shell the source host and port would be localhost and some random port. It can be useful for the login procedure or other service to have the actual client host name (or IP address). Adding the path setting.

# WASD_CONFIG_MAP [[*:22345]] pass * raw://localhost:22 notimeout proxy=forwarded=address
will result in connection data becoming available in the multivalued logical name WASD_TUNNEL. Index 0 contains internal data, and then the rest (1..127) contain one tunneled connection's details each, in the format
internal-host:port>=external-host:port>=client-host:port>
For example
localhost:46851=www.external.net:22345=mydotcom.org:49201

Obtaining the SSH source port, say from TT_ACCPORNAM data, the original client host and port can be searched for with some trivial DCL code. Adapt to suit local requirements.

$ if P1 .eqs. "" then P1 = f$element(1,":",f$getdvi("TT:","TT_ACCPORNAM")) $ value = "" $ local = "" $ service = "" $ client = "" $ index = 1 $ index_loop: $ value = f$trnlnm("WASD_TUNNEL","WASD_TABLE",index) $ if value .eqs. "" then goto end_index_loop $ local = f$element(0,"=",value) $ addr = f$element(0,":",local) $ port = f$element(1,":",local) $ if port .eqs. P1 $ then $ service = f$element(1,"=",value) $ client = f$element(2,"=",value) $ goto end_index_loop $ endif $ index = index + 1 $ goto index_loop $ end_index_loop: $ if f$trnlnm("TT_CLIENT","LNM$PROCESS") .nes. "" - then deassign /process TT_CLIENT $ if client .nes. "" then define /process TT_CLIENT "''client'"

The tunnel data remains current for at least one minute and may become unavailable at any time after that.

##### Note

The source data only reflects the client that connects to that system's services and so cannot be used across multiple, back-to-back tunnels.

↩︎ | ↖︎ | ↑︎ | ↘︎ | ↪︎