Closed Bug 492558 Opened 15 years ago Closed 15 years ago

HTTPS Proxy authentication redirects via 403 are not followed

Categories

(Core :: Networking: HTTP, defect)

Product:
Core
Component:
Networking: HTTP
Version:
1.9.2 Branch
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: ddafonte, Unassigned)

References

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; fr; rv:1.8.1.16) Gecko/20080702 Firefox/2.0.0.16
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.10

We have found a critical issue with authentication portal that can occur with any proxy configuration (BlueCoat architecture for example).
With authentication portal, the Proxy redirects url to the authentication portal and then, when authenticated, to the proxy.
There is no problem with HTTP (because HTTP can be redirect by 302 ), the problem occurs with HTTPS trafic.
With non-redirectable trafic, the proxy implements a feature : the proxy returns code 403 . This 403 return code contains html and javascript code that redirects trafic to the authentication portal.
For Firefoxs versions > 3.0.10, the 403 proxy return page is not loaded in the explorer.

Example : 
	- Your are not authentified
	- You connect to https://www.A.com via proxy
	- The Proxy cannot redirect you to https://authenticationurl/https/www.A.com. It answers 403 return code. This 403 page contains an html an javascript redirect you to https://authenticationurl/https/www.A.com
	- You are authenticated 401 authentication on the authentication portal. This authentication portal redirect you to https://www.A.com
	- You connect to https://www.A.com via proxy. Proxy knows user is authenticated (IP, cookie confidence).

Firefox > 3.0.10 is not Authentication portal compliance (authentication portal is implemented in Bluecoat, NetApp, SecureComputing, IronPort...)

The problem seems to come from the feature  nsHttpChannel::ProcessFailedSSLConnect in :

	"    default:
        rv = NS_ERROR_PROXY_CONNECTION_REFUSED; 
        break;
	"

Reproducible: Always

Steps to Reproduce:
	- Your are not authentified
	- You connect to https://www.A.com via proxy
	- The Proxy cannot redirect you to https://authenticationurl/https/www.A.com. It answers 403 return code. This 403 page contains an html an javascript redirect you to https://authenticationurl/https/www.A.com
	- You are authenticated 401 authentication on the authentication portal. This authentication portal redirect you to https://www.A.com
	- You connect to https://www.A.com via proxy. Proxy knows user is authenticated (IP, cookie confidence).
Actual Results:  
error : Proxy connection refused.

Expected Results:  
Access to https://www.A.com
Summary: Critical issue with proxy authentification → Critical issue with proxy authentication
Summary: Critical issue with proxy authentication → HTTPS Proxy authentication redirects via 403 are not followed
Version: unspecified → 3.0 Branch
I can also consistently reproduce this error.  I see it most often when sites use Google Analytics, FF will hang and "Waiting for ssl.google-analytics.com..." will display in the status bar.  A workaround I used is to add a hosts file entry for ssl.google-analytics.com pointing to 127.0.0.1 and to add the hostname to the proxy exception list with a manual proxy config.
This seems to happen for some sites and for other sites FF is able to got through.

FF got hung for page : https://cp.hdfcinsurance.com/CPWeb/

After the workaround as given by Shawn FF was able to open the page.

However, the page opens fine in IE8, Chrome and Safari 4.0
I consistently get this error, with very common sites too (http://www.blogger.com), only solution for me is to specify an exception for ssl.google-analytics.com as my proxy is configured my a pac script which I cannot modify this is a royal pain.  

The pages work fine in IE7.
This also occurs when logging into Google Analytics - quite annoying for a web developer.
This is also the case for http - not only https
Flags: blocking-firefox3.6?
Just discovered the Google Analytics issue which is very annoying for the webpages I'm making. I've heard that the older version of the analytics code does work but haven't had time to try it yet.
--> Core::Networking
Component: General → Networking: HTTP
Flags: blocking-firefox3.6?
Product: Firefox → Core
QA Contact: general → networking.http
Version: 3.0 Branch → 1.9.2 Branch
Flags: blocking1.9.2?
The behavior here, at least for HTTPS, is definitely the result of the fix for bug 479880.   To avoid a security hole, we no longer parse HTML replies from  proxies for HTTPS (and thus any redirect code they contain is not executed). 

My impression was that all the major browser vendors had a similar security hole, and did something similar to this as the fix, other than Opera (which I remember parsing the failed auth replies).  Perhaps I've misremembered, or our bug reporters are not checking with the latest browser versions, or the other browsers have done something specific with 403 replies to support Authentication Portal specifically.

I will look into this.   In the meantime:

> There is no problem with HTTP (because HTTP can be redirect by 302).

Firefox *does* support proxy redirects of HTTPS via 3xx codes, so this is an alternative to using 403 redirects.  We had a version or two of Firefox where this was broken, but it works in 3.5.  However, it now only works for top-level loads, not iframes or scripts.  See bug 491818.  Also, none of the other major browsers allow 3xx HTTPS redirects, so it's effectively a Mozilla-specific way to redirect.

> This is also the case for http - not only https

I would be very surprised if this is the case, and if it is, it's something else that's causing the problem, as I'm 100% sure of what code is stopping 403 HTTPS redirects, and it shouldn't affect HTTP at all.  hth@scor.dk, can you give me a URL that shows the problem?
I have seen the issue at the website www.scor.dk. If I turn on firebug or yslow the website is halted on google analytics scripts. I know there are other issues as well - but the biggest performance issue is the google analytics script. The issue is best seen in the hours 21-00 GMT - Issue has not been seen in IE (6,7,9) - Opera (9.x and 10) - Safari and Chrome.

Issue has been seen in firefox 3.0.12 and 3.5
IE versions is not 6,7,9 but 6,7,8
Google analytics has been taken of the site for testing - and then no issues were seen in test period of 1 week.
hth,

Thanks for the update.  If I hear you correctly, it sounds like you're running into issues only when you turn on firebug/yslow.  So I'm guessing this is a different bug.  Do you have any evidence that the bug you're seeing involves HTTPS 403 redirects?  If not, we can open a separate bug for the issue you're seeing.
I've verified that Safari 4.0.3 and IE 8 do *not* allow Javascript redirects any more from within the content of 403 replies from HTTPS proxies (like us, they no longer parse any reply content).

I've also tried running https://cp.hdfcinsurance.com/CPWeb/ through an HTTPS proxy with Firefox 3.5, and it appears to work (not hanging, at least: I have no login, so I can't test anything but a failed login).

From the timeline of the bug comments, I suspect that these are users who got hit by the fact that browsers no longer parse HTTPS proxy replies, but noticed it in Firefox first.   So I'm marking this as INVALID for now--please file a new comment if you are still experiencing HTTPS proxy 403 redirects working for some browsers but not Firefox.

The one thing I'd like to look into more is to make sure we're still working with Google Analytics. I assume we would have gotten a lot more bug traffic if it were (still) broken.   Does anyone know of a site we can check to see if things are still happy with FF?
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Resolution: --- → INVALID
I'll try to do some more verification of what the problem is if you are not seeing consistent behavior with the HTTPS proxy.  Using FF 3.5.2 I can reproduce the symptoms consistently following these steps:

1) Go to google.com
2) Sign in to my account (Click the Sign In link in the top-right)
3) Enter my authentication
4) Go to Google Reader by clicking Reader from the "more" menu in the Google page header
5) Log out of my Google account by clicking Sign Out

The sign-out redirect never completes.  I get the "Please wait..." page and the status bar reads "Waiting for ssl.google-analytics.com..."
I also face the same behavior
Typo in my comment above.  Should say using FF 3.5.3 I can reproduce...
Could we add a form in firefox settings where we can configure trusted proxy URLs ? Because such proxies mostly have private IP address and can not be easily attacked from outside.
So you're actually setting the proxy's IP address in Firefox preferences?  Not the proxy's hostname?
Oh, and even if you're setting it as an IP address, you lose as soon as that computer is not on the network it expects to be on (say in a hotel).  So I'm not sure the whitelisting you suggest would in fact be secure no matter what.
Shawn,

I'm seeing logouts from Google reader working fine in Firefox 3.5.3, using squid as my HTTP/HTTPS proxy.

Anyone else who thinks there is still something broken:  please post a detailed set of instructions for reproducing.   Also make sure that the site works with IE8 or Safari 4 or some other current browser.
I can logout/login from/in Google reader using a squid as my HTTP/HTTPS proxy only when i put "ssl.google-analytics.com" into my 'No proxy for' list.

If i remove "ssl.google-analytics.com" from my 'No proxy for' list the page just hangs at "waiting for ssl.google-analytics.com" during both login and logoff from google reader.

However, Gmail works fine.

I am using FF 3.5.3.
Flags: blocking1.9.2?
PLEASE FIX THIS FIREFOX!!!  Firefox will hang up "Waiting for
ssl.google-analytics.com..."
Comment 25 seems to have nothing to do with this bug.
(In reply to comment #26)
> Comment 25 seems to have nothing to do with this bug.

closest thing i have found in this forum.  others have reported same hang.
> closest thing i have found in this forum.

So?  If it's not the _same_, then file a separate bug.  Your issue really has absolutely nothing to do with this bug; please stop spamming it.
HI all,

I am still facing this issue. 

Firefox will hang up "Waiting for www.google-analytics.com..."
I tried with the couple of work arounds like addding 'www.google-analytics.com' in the exceptions. 

But this is not a permanent solution. As I cant say to each and every user to add the same in Firefox.

If anyone is having any solution please let me know. I am really in need of a solutions of this.

Thanks in advance
Arunangshu
Arunangshu,

Does this happen every time you request something from www.google-analytics.com?  What exactly is your usage pattern?  And which version of firefox are you on?  Thanks.
You need to log in before you can comment on or make changes to this bug.