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____