Closed Bug 637361 Opened 12 years ago Closed 12 years ago

SSL pages don't work when using a NTLM proxy

Categories

(Core :: Networking: HTTP, defect)

Product:
Core
Component:
Networking: HTTP
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED FIXED
Tracking Flags:
Tracking Status
blocking2.0 --- final+

People

(Reporter: mozilla, Assigned: briansmith)

References

(
URL
)

Details

(Keywords: qawanted, regression, Whiteboard: [hardblocker][fixed with back out bug 573043]) 

User-Agent:       Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; [eburo v2.0]; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)
Build Identifier: Firefox 4b12

With the last Beta 12, the connection to SSL sites thought authenticated NTLM proxy doesn't work.

This bug was resolved in FF4b8 or 9 but reappears with beta12
Cf. https://bugzilla.mozilla.org/show_bug.cgi?id=592197

Reproducible: Always

Steps to Reproduce:
1. go to an https site
2. 
3.
Actual Results:  
Connection refused by proxy juste after

Expected Results:  
Connection

Mozilla/5.0 (Windows NT 5.1; rv:2.0b12) Gecko/20100101 Firefox/4.0b12
Keywords: regression
Did it work with b11 ?
GaaL, can you please narrow down when this broke using nightly builds?
My girlfriend just hit this at work, b11 works, b12 broke with the same symptoms.  It's not clear if she's on an NTLM proxy, but I suspect she is based on what I know of that setup.  Pretty sure this is a hardblocker, since it's not something that can be worked around on the user side.  IE/Chrome are, obviously, unaffected.  Will relay more if she has time to muck around.
blocking2.0: --- → ?
Mike, we need that regression range!
Status: UNCONFIRMED → NEW
Ever confirmed: true
Do we have an NTLM proxy we can test with?
Keywords: qawanted
(In reply to comment #1)
> Did it work with b11 ?

Yes, perfectly.
(In reply to comment #2)
> GaaL, can you please narrow down when this broke using nightly builds?

I will. But tomorrow at work, not before 9am CET ;-)
I asked QA if we had an NTLM proxy to test with and the answer was "no, but ask abillings". CC'ing abillings.
Assignee: nobody → bsmith
blocking2.0: ? → final+
Whiteboard: [hardblocker]
Ask me?

QA doesn't have NTLM setup. We've had people test on their own systems in the past.

It is possible to investigate what it would take to get some kind of NTLM system but it won't be quick.
Looks pretty quick if you can wrangle a linux VM:

http://www.flatmtn.com/article/setting-squid-ntlm-auth

This is a FF4 blocker and thus high priority. Ping me if it is interfering with branch work and we'll discuss priorities.
I'm not onsite in the office until Wednesday, Christian, so it is hard for me to set up a server and have it be accessible. I can certainly wrangle a linux VM if someone can find me a place to deploy it.
See bug 573043. I am working on creating a proxy VM for testing. It seems like Honza already has such an environment too.
See Also: → 573043
(In reply to comment #10)
> Looks pretty quick if you can wrangle a linux VM:
> 
> http://www.flatmtn.com/article/setting-squid-ntlm-auth

I'd need someone to give me a remotable machine that I could run the linux VM
on that others could hit. Reading the page above, we still need an Windows NT
domain controller on its network as well. Do we have one in house that is
available?
Hi, first post! Didn't notice this earlier (mostly at home) and after some attempts I believe this is different to Bug 592197 which I also experienced:

* In Bug 592197 I could not enter ANY site using https: from my workplace (NTLM proxy by Microsoft's ISA Server) unless I started Private Browsing; this was a reliable workaround. Cannot remember whether a non-Private Browsing attempt timed out with a message.

* Now the Private Browsing workaround no longer works: with b12 either Normal or Private Browsing will keep waiting for the site for several minutes (can't say whether this stops after a longer period). Also, not every https: site is affected: I can enter Mozilla's wiki and bugzilla (I registered right now from my workplace) but I cannot enter AMO.

I will try all this at home, without an NTLM proxy in the way.
(In reply to comment #13)
> I'd need someone to give me a remotable machine that I could run the linux VM
> on that others could hit. Reading the page above, we still need an Windows NT
> domain controller on its network as well. Do we have one in house that is
> available?

I am building a test network (DC, proxy, client) in VMWare now. After some false starts, I have the DC done (AFAICT) and I'm working on the proxy and client.
The platform may not be only x86 Windows XP. On Windows 7 (with NTLM proxy), I am unable to access https://addons.mozilla.org/ though I can access bugzilla, https://duckduckgo.com/ etc.
I'm seeing this at work. I get

works:
Mozilla/5.0 (Windows NT 6.1; rv:2.0b12pre) Gecko/20110208 Firefox/4.0b12pre
http://hg.mozilla.org/mozilla-central/rev/3470891975c7            

fails:
Mozilla/5.0 (Windows NT 6.1; rv:2.0b12pre) Gecko/20110209 Firefox/4.0b12pre
http://hg.mozilla.org/mozilla-central/rev/fd0817e454fe
(In reply to comment #17)
> I'm seeing this at work. I get
> 
> works:
> Mozilla/5.0 (Windows NT 6.1; rv:2.0b12pre) Gecko/20110208 Firefox/4.0b12pre
> http://hg.mozilla.org/mozilla-central/rev/3470891975c7            
> 
> fails:
> Mozilla/5.0 (Windows NT 6.1; rv:2.0b12pre) Gecko/20110209 Firefox/4.0b12pre
> http://hg.mozilla.org/mozilla-central/rev/fd0817e454fe

Regression window:

http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=3470891975c7&tochange=fd0817e454fe
(In reply to comment #17)
> I'm seeing this at work. I get
> works:
> Mozilla/5.0 (Windows NT 6.1; rv:2.0b12pre) Gecko/20110208 Firefox/4.0b12pre
> http://hg.mozilla.org/mozilla-central/rev/3470891975c7            
> fails:
> Mozilla/5.0 (Windows NT 6.1; rv:2.0b12pre) Gecko/20110209 Firefox/4.0b12pre
> http://hg.mozilla.org/mozilla-central/rev/fd0817e454fe


I confirm. Same conclusion at my work.
Bug 573043 is most likely in that regression range.
Not sure if this is helpful, but I found that if I set network.auth.force-generic-ntlm to true, the password manager will ask for and store my credentials. When looking using wireshark, on the connect request, the 'Proxy-Authorization: NTLM T1xxxxx' request header is missing in b12 (versus b11).
(In reply to comment #21)

You're right. 
After forcing "network.auth.force-generic-ntlm" to true, Firefox connects to https sites. But the proxy credentials needs to be enterred by hand.
If there's no simple fix for this we should back out bug 573043, which was an enhancement to existing support.

cc'ing jst, I think he was working on purchasing an ms proxy/web server for testing purposes.
Blocks: 573043
I just double checked with wireshark again, and after I set "network.auth.force-generic-ntlm" to true and I have put in my credentials manually, the request does correctly show:
    CONNECT lwn.net:443 HTTP/1.1
    User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:2.0b12) Gecko/20100101 Firefox/4.0b12
    Proxy-Connection: keep-alive
    Host: lwn.net
    Proxy-Authorization: NTLM TlRM.....
And it correctly goes through the NTLM handshake and all that.
Whiteboard: [hardblocker] → [hardblocker][can be fixed with back out bug 573043]
I'm experiencing troubles with FF4 trunk builds for last one year and I do not think it worked at least once for me. FFX 3.6 and older are fine.
It is to access our company email, Lotus Notes WebAccess 7.01, on SSL, via proxy on MS IIS server, but every time I receive error message (when opening mailbox, after authentization, not sooner, and it is not happening on calendar view).

I'm getting message: Domino Web Access Warning. Sorry, we were unable to process your request at this time. If you are unable to continue working in your mail file, please dismiss this warning and then select View, Reload from your browser's menu.

How can I help you more? I'm trying latest trunk build without success...
It is highly probable that we will just back the bug 573043 out.  I don't think that we can have a quality patch for it so late in the cycle.

Here [1] will soon be a try build with that bug backed out.  Please everybody that experience this bug, install the try build and check the problem is away.  Don't forget to revert all your preference setting to original values!

Thanks.

[1] http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/honzab.moz@firemni.cz-0fdf75ce9911
I have reproduced the bug in VMWare on Windows 7 exactly as described in Comment 14 and Comment 16 but I haven't been able to get the workaround described by setting network.auth.force-generic-ntlm=true as described by comment 21 to work.
Brian is building with the patched backed out to confirm that this fixes the issue and then will land the patch. ETA: very soon.
The backout resolves the problem in my test setup. I will land it ASAP.
So, I have a following test environment: a Windows Server 2003 configured as a domain controller, ISA server 2006 eval with HTTP Web Proxy for the internal network on it, a client Windows 7 machine joining the domain, Firefox set to use a proxy on the controller, port 8080.  Password for the proxy must be entered manually as the user I'm using for work is not part of the domain (and I don't want it to be).

With network.auth.force-generic-ntlm = false (default) I can reproduce the problem described in comment 0.  For every https page load I get refusal from the proxy.  I can see: WARNING: NS_ENSURE_TRUE(statusProvider) failed: file netwerk/protocol/http/nsHttpNTLMAuth.cpp, line 406.

With network.auth.force-generic-ntlm = true, https pages load extremely slow and addons.mozilla.org hangs.  It is another bug, IMO.

I'll look at this tomorrow, but I believe we will just back the regressive patch out.
Whiteboard: [hardblocker][can be fixed with back out bug 573043] → [hardblocker][will be fixed with back out bug 573043]
http://hg.mozilla.org/mozilla-central/rev/dad15c7d80d7

I will reopen bug 573043.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
As a mere consumer of firefox, is there anything I should do or test, or should I wait for the next release? In comment 26 I see 'Please everybody
that experience this bug, install the try build' but I have no idea how to download that.
(In reply to comment #32)
> As a mere consumer of firefox, is there anything I should do or test

The tryserver build for windows can be found here:
http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/honzab.moz@firemni.cz-0fdf75ce9911/tryserver-win32/firefox-4.0b13pre.en-US.win32.zip

Extract the zip file to your desktop, run from there and you can test if the fix worked. (Just delete the folder from your desktop when you are done). 

The fix will also be in the 2011-03-03 nightly (I think it will have just missed tonight's nightly) as well as the Firefox 4 RC, when that is released.
Version: unspecified → Trunk
Well, trybuild is behaving in even worse way for me, 'cause warning dialog is displayed not only once, but one-after-another => are thrown again and again.

What is expected to be correct settings?
network.auth.force-generic-ntlm
network.automatic-ntlm-auth.allow-proxies
network.automatic-ntlm-auth.trusted-uris
network.ntlm.send-lm-response

I've tried almost every combination of bool values, in trusted sites directive I've value: http://intranet,https://intranet

Marek
Try build solves this for me. Thanks :)
The try build did not solve the problem for me:
    CONNECT lwn.net:443 HTTP/1.1
    User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:2.0b13pre) Gecko/20110301 Firefox/4.0b13pre
    Proxy-Connection: keep-alive
    Host: lwn.net
Same problem. I set all ntlm config items (network.auth.force-generic-ntlm, network.automatic-ntlm-auth.allow-proxies, network.automatic-ntlm-auth.trusted-uris and network.ntlm.send-lm-response) back to their defaults and I get the request headers above. Setting network.auth.force-generic-ntlm to true gets me back to the dialog where I can input my windows domain/name and password after which it uses that successfully. So this does not seem to have done anything for my situation.

For me (given there's a workaround) this would not be a blocker, but it's a regression for sure.
Michel, others for whom the backout didn't fix things:  If the problem you're seeing is not present in 3.6 but is present in today's nightlies, please file a new bug and try to narrow down which nightly the problem you see first appeared in.  It sounds like there may be more than one underlying problem here, with similar symptoms....
OK. Just to be clear, for me this broke between b11 and b12. Apologies but I am not familiar with how to find (and therefor bisect between) the 'nightlies' and b11. If you can point me in the right direction, I'll be happy to spend sometime this (for my timezone) PM download and try a bunch of different versions.
Michel, you can find nightlies at http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/ in directories by date.

b11 is, I think, about a month ago in terms of dates.  b12 is last week.

Please do file a separate bug if the problem is still there for you in today's nightly?
I'm sure I'm dense here, but I see:
  2011-03-02-03-mozilla-1.9.1/	02-Mar-2011 05:18 	-
  2011-03-02-03-mozilla-1.9.2-debug/	02-Mar-2011 03:00 	-
  2011-03-02-03-mozilla-1.9.2-l10n/	02-Mar-2011 06:05 	-
  2011-03-02-03-mozilla-1.9.2/	02-Mar-2011 06:08 	-
  2011-03-02-03-mozilla-central-debug/	02-Mar-2011 03:00 	-
  2011-03-02-03-mozilla-central-l10n/	02-Mar-2011 07:17 	-
  2011-03-02-03-mozilla-central/	02-Mar-2011 06:58  	-
  2011-03-02-03-tracemonkey/	02-Mar-2011 07:33 	- 
What should I grab?
For a more automated solution to bisecting, check out:
http://harthur.github.com/mozregression/

Will take a minute or two to install, but will save a load of time as it picks the dates and downloads the files for you automatically, all that has to be done is saying "good" or "bad" each time, until the range is narrowed to 24 hrs.

If you would rather do manually, then the answer to your question is:
2011-MM-DD-HH-mozilla-central/

Whereby HH will vary day to day, but normally for Win32 would be 04 or 03. Just look for folders that contain a win32 zip and not 64bit/some other OS.
OK, pulled the binary from 2011-03-02-03-mozilla-central and it's still broken. I'll verify the one from a month ago to double check it works and then I'll try to track down the version with the mozregression thing. Hopefully that does not require access with SSL anywhere...
Michel, please provide more details of your configuration if you know them:

1. Are you using "System Proxy settings", "Manual Proxy Configuration" in Options -> Advanced -> Connection (Settings...)?

2. Do you have per-protocol proxy settings or are you using "Use these settings for all protocols"?

3. Which proxy server are you using (e.g. ISA Server 2006, ForeFront TMG 2010, etc.)?
1. I'm using Manual Proxy configuration for this test. Normally in our environment we'd use a proxy.pac file, but I took that out to keep my test simple (and easier to sniff).
2. Same proxy for all protocols.
3. It's a McAfee Web Gateway.

I tracked down that this broke after the version in the 2011-02-08-03 directory (i.e. that version works, the one in 2011-02-09-03 does not).
That matches the range in comment 17....  which is odd.
Maybe I screwed up my tests. Let me go back to the latest nightly again and verify.
I had been testing this by checking to see if https://addons.mozilla.org/ loads or hangs. It looks like there is a bug that first occurs in 2011-02-16-03-mozilla-central (2011-02-15-03-mozilla-central works). Namely, loading AMO hangs when going through an authenticated NTLM proxy. And, oddly, the backout fixed the AMO hang in my local build but when I try Honza's tryserver builds, the hang is still there. So, it seems like there are two bugs.
Or if they want to give me PDBs, I can give them real stacks and other data.
OK, I also found why I was so confused (i.e. the latest nightly _does_ work)

My workaround was that I set network.auth.force-generic-ntlm to true, and let
the password manager do it's thing. If I start with that config, and then set
the setting to false, and try the SSL site, it does not work. I.e. I need to
start the browser fresh, with network.auth.force-generic-ntlm set to false (the
default) for this to work. I did not do that clean start when I first tried the
nightly, but did so it for the bisect test. <slaps forehead>.

Interestingly enough, looking at the previous comment (48), when I click on
add-ons, it simply hangs for me right now. And trying to open that URL in a
separate tab also hangs.

Having said all that, I am also rather humbled about my testing abilities, and
perhaps you should take what I say with a grain of salt.
I opened bug 638179 for the problem of https://addons.mozilla.org hanging.
Whiteboard: [hardblocker][will be fixed with back out bug 573043] → [hardblocker][fixed with back out bug 573043]
Summary: REOPEN : SSL pages don't work when using a NTLM proxy → SSL pages don't work when using a NTLM proxy
You need to log in before you can comment on or make changes to this bug.