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