Re: Non editorial comments...

Sorry if this is causing more traffic than it should be I will try and 
illustrate how new protocol features can have odd problems when bening used
with older software.

The http-gw is part of the Firewall toolkit and was written to run on a dual
homed bastion host. Initially it was a gopher proxy then expanded to handle
both gopher, http 0.9 and http 1.0 requests. The proxy can work out which
is which.. It was written BEFORE there were proxy aware browsers available.

To get handle gopher and WEB clients, a simple scheme where the proxy 
translated gopher menu items from 
	port 70
	host xyz.com
	path /apath
	type 1

to 
	port 70
	host firewall
	path gopher://xyz.com/11/apath
	type 1

and URLs of the form
	http://xyz.com/apath
to
	http://firewall:80/http://xyz.com/apath

Luckily most browsers of the time had no problems with these translated URLs.
The proxy would see
	GET /http://xyz.com/apth HTTP/1.0
and know that it was a prepended handoff since a proxy aware client sends
	GET http://xyz.com/apath HTTP/1.0

So the one proxy handled gopher requests, http 0.9 and 1.0 requests. With
the http requests in prepend or proxy handoff format. 

Now the proxy still has this functionallity even though we strongly recommend 
that users setup their proxy variables since they get better functionality.

With this sort of proxy, it is possible that a client that supports persistant
connections can be used such that it does not know that it is talking to a
proxy and thus sends the connection: keep-alives instead of the proxy-connection
ones. And things don't work at all well if the server also understands
persistant connections since the proxy has no knowledge of what is going on.

There are 5000-10000 installations of the fwtk or our gauntlet internet firewall
 which is the commercial version. But luckily most use it in hte proxy handoff
configuration and don't have a proxy that does understand persistant proxy
stuff on the internet side.

Alot of our firewall customers want to authenticate outgoing requests from
their users so they can log who is doing what. Using a persistant proxy
connection from the browser to an authenticating http gateway allows the 
use of even basic authentication as a strong auth mechanism where the proxy
talks to an authentication server to findout for this user what auth mechanism
they use (Securid, SNK, S/Key) and sends back as the realm the relevant
tokens challenge.

When a user first uses the proxy, there is an extra proxy authenticate 
'handshake' since the proxy needs to find out the users username before it
can talk to the authserver but once this has been done the client dutifully
re-presents the old credentials and as long as the connection is maintained
the proxy is happy.

With browsers such as netscape you do have to set the number of connections 
down to 1 else you have to auth once for each connection.

If the customer deems that plain text passwords are ok for outbound auth then
client - proxy persistant connections are not mandatory. 

Pete.
-- 
The TIS Network Security Products Group has moved!
voice: 301-527-9500 x123 fax: 301-527-0482
2277 Research Boulevard, 5th Floor, Rockville, MD 20850

Received on Wednesday, 29 May 1996 07:17:06 UTC