Bug#574635: xulrunner: cannot connect through a Bluecoat proxy with REDIRECT authentication

Josselin Mouette joss at debian.org
Tue Mar 23 15:07:06 UTC 2010


Le vendredi 19 mars 2010 à 17:36 +0100, Mike Hommey a écrit :
> On Fri, Mar 19, 2010 at 04:11:49PM +0100, Josselin Mouette wrote:
> > This happens since the fix for the following bug:
> > https://bugzilla.mozilla.org/show_bug.cgi?id=CVE-2009-1836
> > 
> > As comment #75 of said bug explains, it breaks the behavior of some
> > (arguably broken) proxies. When you issue a CONNECT command, they will
> > reply with a REDIRECT to a page that does the authentication.

Actually a new analysis shows this is more complicated than that.

So this is what happens when you request https://blah.blah/
1) The browser issues CONNECT blah.blah
2) The proxy replies 302 found with a redirect to
https://stupid.proxy/blah.blah
3) The browser issues CONNECT stupid.proxy
4) The proxy replies 401 authorization required with some Javascript
code that does a redirect to https://authentication.gateway/blah.blah

Then, the JS code used to be executed. Now it is not and you only get a
boilerplate page.

> Normally this was fixed in 1.9.1 and 1.9.0.16. The upstream bug is
> https://bugzilla.mozilla.org/show_bug.cgi?id=491818 and the current code
> for the nsHttpChannel::ProcessFailedSSLConnect in both the version in
> lenny and the one in testing would fail to reverse the patch you are
> linking, because the code changed. What version did you reverse the
> patch on, exactly ?

Of course the patch has to be adapted before being reversed.

Cheers,
-- 
 .''`.      Josselin Mouette
: :' :
`. `'   “A handshake with whitnesses is the same
  `-     as a signed contact.”  -- Jörg Schilling






More information about the pkg-mozilla-maintainers mailing list