Closed Bug 554612 Opened 14 years ago Closed 8 years ago

cannot connect through a Bluecoat proxy with REDIRECT authentication

Categories

(Core :: Networking: HTTP, defect)

Product:
Core
Component:
Networking: HTTP
Platform:
x86_64
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: joss, Unassigned)

Details

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en; rv:1.9.0.16) Gecko/20080528 Epiphany/2.22 Firefox/3.0
Build Identifier: Xulrunner 1.9.1.8

Xulrunner-based browsers fail to connect through some proxies with very
peculiar settings.

This happens since the fix for bug#479880. 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 redirection to a page that does the authentication.

Bug#491818 was already reported and fixed, which means that proxies replying with a 302 found page are correctly handled. However our BlueCoat proxy does much worse:

HTTP/1.1 403 Forbidden

Cache-Control: no-cache

Pragma: no-cache

Content-Type: text/html; charset=utf-8

Proxy-Connection: Keep-Alive

Connection: Keep-Alive

Content-Length: 513



<html>
<SCRIPT language=javascript>
.window.location.replace( 'http://**************/' + window.location.hostname + window.location.pathname + window.location.search );
</SCRIPT>
<SCRIPT language=javascript>
.document.write('<meta http-equiv="refresh" content="0; URL="http://***************/'+ window.location.hostname + window.location.pathname + window.location.search+'">');
</SCRIPT>
</html>

(I replaced the actual URL of the authentication gateway with stars.)

Currently, the BlueCoat people refuse to fix their proxy, so the only way we found to deal with this is to revert the patch for bug#479880, making the browser vulnerable to CVE-2009-1836 again.

Actually it could be argued that the proxy is actually *exploiting* CVE-2009-1836 in a creative way. It uses the JavaScript code to retrieve the full target URI, which is something that SSL should precisely prevent it from obtaining.

Since it is dangerous to authorize such things, but OTOH it’s the only way to get it to work with such a proxy, we think the only way is to add a configuration setting in about:config which allows the code from proxy errors to be interpreted.

Reproducible: Always

Steps to Reproduce:
1. Install a BlueCoat proxy with an authentication gateway.
2. Try to use Firefox to connect to a HTTPS site.
3. Cry.
> Currently, the BlueCoat people refuse to fix their proxy,

This is in spite of the fact that no browser works with it?

> the proxy is actually *exploiting* CVE-2009-1836

Yes, exactly.  What they're doing is indistinguishable from an attack.

> add a configuration setting in about:config which allows the code from proxy
> errors to be interpreted.

We generally try to avoid "exploit me" settings that people will just blindly toggle...  Who would set this setting?  Under what conditions?  How would they avoid being exploited after setting it?
(In reply to comment #1)
> > Currently, the BlueCoat people refuse to fix their proxy,
> 
> This is in spite of the fact that no browser works with it?

Yes, apparently they even provided a plugin for IE8 to work around it :/

> We generally try to avoid "exploit me" settings that people will just blindly
> toggle...  Who would set this setting?  Under what conditions?  How would they
> avoid being exploited after setting it?

I’d say it requires full trust of the said proxy and of the network that leads to it to be enabled.

Note that I completely understand your POV, I’m just looking for better solutions than a full rebuild of xulrunner just to remove a security safeguard.
> I’d say it requires full trust of the said proxy and of the network that leads
> to it to be enabled.

Right.  So not really an option on any sort of machine that is not physically connected to a single known network at all times...

ccing some more core networking folks.  I suppose we could add a hidden preference for this, but I wonder whether there's a way to make the preference "safe" in some way (whitelisting of some sort... probably not in the face of an untrusted network).

blizzard, do we have any contacts with these BlueCoat people?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Not that I'm aware of, no.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.