On 3/10/2013 5:59 a.m., Babelo Gmvsdm wrote:
As it works on any client when they bypass the proxy, I guess the problem not ony come from the client. But I'll get a log from firefox tomorrow @ work if needed.
NP: client communication through a proxy is very different from client
communication direct to the origin. There are a lot of small details
that have to be changed or mapped between the two sets of lmitations.
Squid works perfectly well for a large percentage of the world
population, therefore it could very well be a client problem with such
mappings.
We can't make such generalizations without specific knowledge of what
the core problem is.
One thing I forgot to mention, my Squid is configured in High Anonymous and in transparent mode.
Well then. That makes things a lot more complicated. Anonymous proxy are
well known for erasing critical headers passed over HTTP for secruity
systems - after all "tracking headers" are used by security systems as
often as marketing. Transparent proxy also introduce a whole host of
problems related to the client not being aware of what protocol level
limitats are.
For example, a secure connection may well be using some non-HTTP
channel to validate security credentials. Passing through an interceptor
proxy corrupts the TCP level details such validation may depend on for
cross-checking or core validity tests. This is an old problem which
screwed with hotmail.com logins and Exchange OWA services for many years.
This is one of the popup which cause the problem(can be viewed as web page):
http://consent-pref.truste.com/?type=ibm&site=ibm.com&action=notice&country=fr&locale=fr&behavior=expressed&from=http://consent.truste.com/&url=http://www.ibm.com/us/en/
I think something is not well accepted by my Squid but I don' t know what.
redbot.org says the Vary header is missing on responses to HTTP/1.1
conditional requests. Without that header the response to that URL will
be corrupted.
and this is it source code:
<!doctype html>
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1">
<noscript>
<div style="width: 22em; position: absolute; left: 50%; margin-left: -11em; color: red; background-color: white; border: 1px solid red; padding: 4px; font-family: sans-serif">
Your web browser must have JavaScript enabled
in order for this application to display correctly.
</div>
</noscript>
</body>
</html>
This is what I think:
Somebody on your network has sent a HTTP/1.1 conditional request to
that URL and caused the above page to get cached. Without Vary header on
that response Squid responds to all following requests using that above
object. Which in the Truste system is an error page. Making all your
clients transactions involving that URL end in an error.
It's an elegant form of DoS attack that can be targeted on any websites
or services depending on consent-pref.truste.com (*any* URL at thet
domain is vulnerable). One single web request able to trigger the denial
until somebody such as yourself complains or looks into it.
While it is a DoS vulnerabiliy, it is also one which can be triggered by
any user accidentally running a tool that fetches the URL through your
proxy. So the cause may not have been malicious.
Amos
