Re: backbone transparent proxy / connection hijacking

[Jon Lewis <jlewis () inorganic5 fdt net>]

On Fri, 26 Jun 1998, Owen DeLong wrote:

> > The Cybercash server performed client authentication based on
> > the IP address of the TCP connection. Placing a proxy (transparent
> > or otherwise) in between clients and that server will break
> > that authentication model. The fix was to simply configure Traffic
> > Server to pass Cybercash traffic onwards without any attempt to
> > proxy or cache the content.
> But, as you point out, this basically requires that each server using
> this authentication model be identified, then corrected on the cache
> server on a case-by-case basis.  While such servers are, at this point,

My main grip with Digex is that they did this (forced our traffic into a
transparent proxy) without authorization or notification.  I wasted an
afternoon, and a customer wasted several days worth of time over a 2-3
week period trying to figure out why their cybercash suddenly stopped
working.  This customer then had to scan their web server logs, figure
out which sales had been "lost" due to proxy breakage, and see to it that
products got shipped out.  This introduced unusual delays in their
distribution, and had their site shut down for several days between their
realization of a problem and resolution yesterday when we got Digex to
exempt certain IP's from the proxy. 

I have nothing against web caching, and even think it's a good idea and
the way of the future.  Digex is just going about this the wrong way.  As
a customer and network administrator, I should be able to choose which of
FDT's traffic is forced into web caches.  When that was the case, we had
no issues with "legacy applications" breaking, because we had no servers
going through caches. 

I think it makes great sense for backbone providers to setup web caches
and use whatever means they feel are justified to encourage customers to
setup their own caches that talk to the backbone caches via ICP or give
the customer the _choice_ to have the backbone provider do all their
caching if the customer does not want to setup their own cache.

> > Inktomi also conducts proactive audits both inside live Traffic
> > Servers and via the extensive "web crawling" we perform as part
> > of our search engine business. The anomalies discovered by these
> > mechanisms are similarly made available to our customers.
> This is a much better and likely more thorough way to gather a list
> of anomolies.  However, given that, I'm surprised you didn't catch
> the CyberCash issue prior to it becoming one.

Yes.  I can't imagine FDT is the only Digex customer that houses servers
that use CyberCash.  As each customer finds an application that breaks due
to transparent proxying, will the others benefit from their debugging, or
does every customer have to jump through the hoops themselves wasting time
rediscovering what breaks?

------------------------------------------------------------------
 Jon Lewis <jlewis () fdt net>  |  Spammers will be winnuked or 
 Network Administrator       |  drawn and quartered...whichever
 Florida Digital Turnpike    |  is more convenient.
______http://inorganic5.fdt.net/~jlewis/pgp for PGP public key____