Jethro Carr wrote:
On Mon, 2009-08-10 at 10:18 +1200, Jethro Carr wrote:
hi all,
Thanks for the replies (on and off-list), several people have confirmed the existence of a proxy for international traffic for telstraclear customers.
Will talk to Telstraclear's support desk and hopefully get it disabled for my account, which some other people have been able todo.
Otherwise will have to work around with some ssh magic.
no luck with Telstraclear, took me quite some time to get to someone who actually knew what a cache was.
Whilst the guy was polite enough, he seemed unable to understand that setting cache control on my apache server isn't going to do anything to help resolve the problem, when the problem is the cache using the DNS lookups to resolve the server.
I did manage to determine that the only reason they will put an exclude into their cache is for legal reasons or very specific applications that break the cache, clearly I'm not VIP enough for that service.
Also told that their system does not allow them to disable the cache on a per-customer basis at all.
Will have to do some SSH proxy stuff order to perform my testing.
Thanks to everyone who replied so promptly! :-)
regards, jethro
I know its a bit late or this issue, but I thinks its worth donning my Squid-cache hat anyway and explaining a little about transparent proxy operation the nobody seems to have considered. If I understand the problem from Jethros earlier posts he was using a remote server with virtual hosting and setting the hosts file on his local computer to access it. This has two effects: - browser visits the remote IP - browser sends the HTTP headers for whatever virtual-hosted domain was wanted. Which is fine for testing in a LAN where there are no proxies present. However any middle proxy _cannot_ trust the destination IP, far too many security attacks are based on sending doctored requests to an IP they should not go to. So, now we get to the transparent proxy. Up until recently they all performed DNS on the HTTP listed domain and most redirected the request to the actual destination. So that a) the request gets the right data back via the optimal route, and b) in the case of a hijacking attacks the real domain owner gets some warning + victim hopefully gets to notice something is broken. (Sorry Jethro, local-machine hosts file is nearly useless when crossing the Internet.). Recently there have been proof-of-concept and zero-day attacks using http://www.kb.cert.org/vuls/id/435052 so the proxy behaviour is changing. Some are re-writing the URL and Host: headers to raw IPs and passing it through (bye-bye virtual hosting), some are passing the request to the original IP regardless of the cost, others are validating the destination + headers and throwing up attack notices if they don't match. Neither of which helps Jethro, except to inform that Telstra are not at fault. Their proxy is behaving properly in this case and blocking his hijack redirection. Had the proxy worked as assumed, it would possibly have poisoned the cache for every other Telstra client who then get shown the test site he wanted hidden. Best-practice for such testing of remote servers needs to involve DNS (possibly on a dummy domain). Or as he already discovered: raw-IP in the URL gets through just fine. Though may not be possible for virtual hosts. HTH AYJ