Closed Bug 1150069 Opened 9 years ago Closed 2 months ago

Firefox 37 will not fail to Basic authentication for proxy on Mac OS X

Categories

(Core :: Networking: Proxy, defect, P3)

Product:
Core
Component:
Networking: Proxy
Version:
37 Branch
Platform:
Other
macOS
Type:
defect

Tracking

()

Status:
RESOLVED INCOMPLETE

People

(Reporter: tommy, Unassigned)

References

Details

(Whiteboard: [necko-backlog][ntlm]) 

User Agent: Mozilla/5.0 (Windows NT 6.1; rv:37.0) Gecko/20100101 Firefox/37.0
Build ID: 20150326190726

Steps to reproduce:

Upgrading from FF 36.0.4 to 37 now prevents Mac OS X users from authenticating to our McAfee Web Gateway proxies using Basic authentication.  After reverting back to 36.0.4, the access again works.  Something happened in FF 37 that does not allow the browser to fail to Basic when NTLM fails.


Actual results:

Users are getting 407 authentication errors due to the browser only attempting NTLM connections, which due to our security controls, will not work for our Macs.  The Basic authentication that worked up to FF 36.0.4 is not longer working in FF 37.


Expected results:

What should have happened is that once the NTLM fails, the expected behavior is for the authentication to allow Basic against our proxies.  This is not working.
OS: Windows 7 → Mac OS X
Hardware: x86 → Other
Patrick, some info the reporter can provide to help the devs?
Component: Untriaged → Networking
Flags: needinfo?(mcmanus)
Product: Firefox → Core
I think dragana worked in this space recently.. if not, pass the ball to ? valentin?
Flags: needinfo?(dd.mozilla)
I could not find anything obvious that changed between 36 and 37.

Can you send me a http log with 37?
https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/HTTP_logging

You can also send it to me per e-mail if you prefer.

Thanks.
Flags: needinfo?(tommy)
I have logged results for both FF 36.0.4 and 37, but I will need to redact it pretty heavily if needed, due to security reasons.  In the interim, here is a snippet I found that appears to show the difference regarding older FF versions correctly failing back to Basic authentication, and how FF 37 does not:

Firefox 36.0.4:
2015-04-02 13:00:28.239585 UTC - 2074251648[100562110]: nsHttpAuthCache::GetAuthEntryForDomain [key=http://proxy.web.XXX.XXX:80 realm=]
2015-04-02 13:00:28.239593 UTC - 2074251648[100562110]: nsHttpNTLMAuth::ChallengeReceived [ss=0 cs=0]
2015-04-02 13:00:28.239600 UTC - 2074251648[100562110]: Force use of generic ntlm auth module: 0
2015-04-02 13:00:28.239606 UTC - 2074251648[100562110]: Default credentials allowed for proxy: 1
2015-04-02 13:00:28.243275 UTC - 2074251648[100562110]: Native sys-ntlm auth module not found.
2015-04-02 13:00:28.243316 UTC - 2074251648[100562110]: Allow use of generic ntlm auth module: 0
2015-04-02 13:00:28.243323 UTC - 2074251648[100562110]: No ntlm auth modules available.
2015-04-02 13:00:28.243399 UTC - 2074251648[100562110]: nsHttpChannelAuthProvider::GetAuthenticator [this=11ff7c200 channel=1105b4c10]
2015-04-02 13:00:28.243415 UTC - 2074251648[100562110]: nsHttpChannelAuthProvider::GetCredentialsForChallenge [this=11ff7c200 channel=1105b4c10 proxyAuth=1 challenges=Basic realm="XXX"]
2015-04-02 13:00:28.243430 UTC - 2074251648[100562110]: nsHttpAuthCache::GetAuthEntryForDomain [key=http://proxy.web.XXX.XXX:80 realm=XXX]
2015-04-02 13:00:28.243443 UTC - 2074251648[100562110]:   identity invalid = 1
2015-04-02 13:00:28.243447 UTC - 2074251648[100562110]: nsHttpChannelAuthProvider::PromptForIdentity [this=11ff7c200 channel=1105b4c10]
2015-04-02 13:00:28.254421 UTC - 2074251648[100562110]: Suspending the transaction, asynchronously prompting for credentials

Firefox 37:
2015-04-02 12:30:17.671656 UTC - 2074251648[100563110]: nsHttpAuthCache::GetAuthEntryForDomain [key=http://proxy.web.XXX.XXX:80 realm=]
2015-04-02 12:30:17.671664 UTC - 2074251648[100563110]: nsHttpNTLMAuth::ChallengeReceived [ss=11efa34d0 cs=0]
2015-04-02 12:30:17.671671 UTC - 2074251648[100563110]: Force use of generic ntlm auth module: 0
2015-04-02 12:30:17.671676 UTC - 2074251648[100563110]: Trying to fall back on internal ntlm auth.
2015-04-02 12:30:17.671683 UTC - 2074251648[100563110]:   identity invalid = 1
2015-04-02 12:30:17.671688 UTC - 2074251648[100563110]:   taking identity from auth cache
2015-04-02 12:30:17.671693 UTC - 2074251648[100563110]: nsHttpNTLMAuth::GenerateCredentials
2015-04-02 12:30:17.671710 UTC - 2074251648[100563110]: nsHttpAuthCache::SetAuthEntry [key=http://proxy.web.XXX.XXX:80 realm= path= metadata=1efa34d0]

Let me know if you still need the logs, and I will provide them.  Thanks for the quick attention to this issue.
Flags: needinfo?(tommy)
To hopefully assist further, I have sent Dragana the redacted HTTP logs from both FF 36.0.4 and FF 37.  Please let me know if I can provide anything else.  Thanks!
Thank you very much.
Flags: needinfo?(dd.mozilla)
This is connected to bug 423758.

 	
Andrew, can you take a look at comment #4
Flags: needinfo?(abartlet)
Blocks: 423758
Fixing bug 423758 implemented NTLMv2 authentication and enabled it by default. The old and insecure NTLMv1 authentication was already disabled by default in Firefox 36 and older versions (except when used over https).

Please note that downgrading the security protocol is considered a major security problem (search for POODLE). I don't know if such logic applies to the problem encountered by the reporter. I would say - if you don't want to support an authentication method, don't advertise it to the clients.
Just to note, we are working on enabling Kerberos, but until then, and due to our authentication policies having been moved to only allow NTLMv2, we have had to fall back on Basic authentication for our Macs as an interim solution.  As Macs are unable to support proxy authentication via NTLMv2, Basic is what we had to utilize.  Of course, now, this capability seems to have ceased when moving from FF 36.0.4 to 37.  Trust me, I would much rather use NTLMv2 or Kerberos, but I would like to continue using Basic until we are able to move in that direction on our non-Windows clients.
I'm still not convinced you have a good case to claim that your setup is sane and Firefox has a bug. A limitation, maybe.

Firefox could help you if there was a way to disable NTML completely or to a specific host, or maybe to non-https hosts as before. It looks like we lost that functionality. Apparently the thinking was - NTMLv2 is so much better than NTLMv1, why would anyone want to disable it? Yet somebody needs that, as it turns out.
Not that I thought it would, but the latest 37.0.1 is still not allowing Basic authentication to function.  As for your comments, Pavel, you have no argument from me on the sanity of doing things the way we are doing it.  My desire is to allow non-Windows clients to use Kerberos, but we are just not there yet.  I just want to maintain my authentication abilities in the interim with the latest version of Firefox, if possible, until we can do the "right" thing with this. :)
Since the original patch removed the "network.negotiate-auth.allow-insecure-ntlm-v1" setting, that part of the patch could be manually reverted. The setting should probably be renamed to "network.negotiate-auth.allow-ntlm", defaulting to "true". I hope that patch could be treated as a revert and get to a release quickly. Separate handling of https is probably not justified; it was a compromise solution to allow the knowingly broken NTMLv1 protocol over secure connections.
Exposed use case (URL) demonstrating that it works in 36 and doesn't in 37 would help.  I would then take a look sooner.

I think this is somewhere in the layers around NTLM, not in the module itself.
First looking again at your log i see that firefox is prompting the user for identity. Do you see something?

I try to reproduce your problem and i got prompted for ntlm and if I click cancel it prompt again for basic.

In your case the second prompt should say "XXX" because that is the realm for basic authentication.
Flags: needinfo?(tommy)
(In reply to Pavel Roskin from comment #12)
> Since the original patch removed the
> "network.negotiate-auth.allow-insecure-ntlm-v1" setting, that part of the
> patch could be manually reverted. The setting should probably be renamed to
> "network.negotiate-auth.allow-ntlm", defaulting to "true". I hope that patch
> could be treated as a revert and get to a release quickly. Separate handling
> of https is probably not justified; it was a compromise solution to allow
> the knowingly broken NTMLv1 protocol over secure connections.

I don't understand what you are asking for, but "network.negotiate-auth.allow-insecure-ntlm-v1" essentially became "network.auth.force-generic-ntlm-v1"
Flags: needinfo?(abartlet)
(In reply to Tommy Myers from comment #9)
> Just to note, we are working on enabling Kerberos, but until then, and due
> to our authentication policies having been moved to only allow NTLMv2, we
> have had to fall back on Basic authentication for our Macs as an interim
> solution.  As Macs are unable to support proxy authentication via NTLMv2,
> Basic is what we had to utilize.  Of course, now, this capability seems to
> have ceased when moving from FF 36.0.4 to 37.  Trust me, I would much rather
> use NTLMv2 or Kerberos, but I would like to continue using Basic until we
> are able to move in that direction on our non-Windows clients.

I'm confused, but why are the macs unable to do NTLMv2?
I would never guess that a setting that had "allow" in its name has "force" now and behaves the same way. Anyway, it's probably worth a shot. Tommy Myers, could you please check if setting "network.auth.force-generic-ntlm-v1" would fix the authentication? Also please try playing with other about:config settings with "ntlm" in the name, one by one.
(In reply to Andrew Bartlett from comment #16)
> (In reply to Tommy Myers from comment #9)
> > Just to note, we are working on enabling Kerberos, but until then, and due
> > to our authentication policies having been moved to only allow NTLMv2, we
> > have had to fall back on Basic authentication for our Macs as an interim
> > solution.  As Macs are unable to support proxy authentication via NTLMv2,
> > Basic is what we had to utilize.  Of course, now, this capability seems to
> > have ceased when moving from FF 36.0.4 to 37.  Trust me, I would much rather
> > use NTLMv2 or Kerberos, but I would like to continue using Basic until we
> > are able to move in that direction on our non-Windows clients.
> 
> I'm confused, but why are the macs unable to do NTLMv2?

As far as I have read and have been able to implement, NTLMv2 on Macs only works for SMB share access, but will not work for proxy authentication.  The proxy authentication for the OS seems to only allow NTLMv1 or Kerberos.  Firefox, up till version 37 would allow Basic authentication as a failover, when allowed as a method on our proxy servers.  Now, it does not.  In fact, I can open 36.0.4, and everything works fine.  So, I guess I should clarify that NTLMv2 is just not possible (as far as I have seen) for the proxies.
Flags: needinfo?(tommy)
(In reply to Pavel Roskin from comment #17)
> I would never guess that a setting that had "allow" in its name has "force"
> now and behaves the same way. Anyway, it's probably worth a shot. Tommy
> Myers, could you please check if setting
> "network.auth.force-generic-ntlm-v1" would fix the authentication? Also
> please try playing with other about:config settings with "ntlm" in the name,
> one by one.

I have actually tried variations of changing the default values for all of the settings below to no avail:

network.auth.force-generic-ntlm
network.auth.force-generic-ntlm-v1
network.automatic-ntlm-auth.allow-non-fqdn
network.automatic-ntlm-auth.allow-proxies

Those are the only boolean type settings that I found that pertain to the NTLM settings.
Thanks! That confirms that there is no suitable option for your setup, so having an option to globally disable NTLM would be useful for you.
Hi Tommy,

I have Looked into the log that you have sent me and I see that firefox is prompting the user for identity. Do you see something?

2015-04-02 12:30:06.327473 UTC - 2074251648[100563110]: nsHttpChannelAuthProvider::PromptForIdentity [this=11d2085c0 channel=11ccf2430]
2015-04-02 12:30:06.364255 UTC - 2074251648[100563110]: Suspending the transaction, asynchronously prompting for credentials


I try to reproduce your problem and i got prompted for ntlm and if I click cancel it prompt again for basic. (I admit that I have configured just a simple proxy so maybe my proxy is not perfect but i get the same 407 response from the proxy)
Flags: needinfo?(tommy)
Hi, I'm working on Ubuntu 14.04 LTS and I encountered the same problem: after I've upgraded 
FF to 37 now prevents Ubunto users from authenticating to MS ForeFront TMG proxy. The same happens when Ubuntu users  try to login to MS IIS Web Site. In all cases they are getting 407 authentication errors.
Flags: needinfo?(tommy)
Actually sorry, I still want to ask question from comment #21

Maybe we will need additional log
Flags: needinfo?(tommy)
A network trace (eg wireshark) (realising that it would contain not-very-strongly encrypted passwords) may be helpful in understanding why NTLMv2 isn't working, or at least clarify what is going on, along with the logs.
(In reply to Dragana Damjanovic [:dragana] from comment #21)
> Hi Tommy,
> 
> I have Looked into the log that you have sent me and I see that firefox is
> prompting the user for identity. Do you see something?
> 
> 2015-04-02 12:30:06.327473 UTC - 2074251648[100563110]:
> nsHttpChannelAuthProvider::PromptForIdentity [this=11d2085c0
> channel=11ccf2430]
> 2015-04-02 12:30:06.364255 UTC - 2074251648[100563110]: Suspending the
> transaction, asynchronously prompting for credentials
> 
> 
> I try to reproduce your problem and i got prompted for ntlm and if I click
> cancel it prompt again for basic. (I admit that I have configured just a
> simple proxy so maybe my proxy is not perfect but i get the same 407
> response from the proxy)

In my environment, I keep seeing NTLM requests over and over again, and it never fails over to Basic authentication, even though in a packet capture it shows Basic and the correct realm as an option.  Again though, reverting back to 36.0.4 allows it to work.

As for providing a packet capture, unfortunately, due to the nature of my environment, I am not going to be able to provide that information.  If there is any other information I can provide, please let me know.
Flags: needinfo?(tommy)
This is log that I have made. I have set up a test proxy. The requset is the same as I have received from Tommy (authentication headers are the same).


2015-04-09 20:10:23.834411 UTC - -1665145088[7f5bb6868a40]: nsHttpTransaction::OnSocketStatus [this=7f5b80d71400 status=804b0006 progress=3859]
2015-04-09 20:10:23.834418 UTC - -1665145088[7f5bb6868a40]: nsHttpTransaction::ProcessData [this=7f5b80d71400 count=3859]
2015-04-09 20:10:23.834424 UTC - -1665145088[7f5bb6868a40]: nsHttpTransaction::ParseHead [count=3859]
2015-04-09 20:10:23.834432 UTC - -1665145088[7f5bb6868a40]: nsHttpTransaction::ParseLine [HTTP/1.1 407 Proxy Authentication Required]
2015-04-09 20:10:23.834437 UTC - -1665145088[7f5bb6868a40]: nsHttpResponseHead::ParseVersion [version=HTTP/1.1 407 Proxy Authentication Required]
2015-04-09 20:10:23.834444 UTC - -1665145088[7f5bb6868a40]: Have status line [version=11 status=407 statusText=Proxy Authentication Required]
2015-04-09 20:10:23.834448 UTC - -1665145088[7f5bb6868a40]: nsHttpTransaction::ParseLine [Server: squid/3.3.8]
2015-04-09 20:10:23.834455 UTC - -1665145088[7f5bb6868a40]: nsHttpTransaction::ParseLine [Mime-Version: 1.0]
2015-04-09 20:10:23.834460 UTC - -1665145088[7f5bb6868a40]: nsHttpTransaction::ParseLine [Date: Thu, 09 Apr 2015 20:10:23 GMT]
2015-04-09 20:10:23.834464 UTC - -1665145088[7f5bb6868a40]: nsHttpTransaction::ParseLine [Content-Type: text/html]
2015-04-09 20:10:23.834469 UTC - -1665145088[7f5bb6868a40]: ParseContentType [type=text/html]
2015-04-09 20:10:23.834474 UTC - -1665145088[7f5bb6868a40]: nsHttpTransaction::ParseLine [Content-Length: 3338]
2015-04-09 20:10:23.834478 UTC - -1665145088[7f5bb6868a40]: nsHttpTransaction::ParseLine [X-Squid-Error: ERR_CACHE_ACCESS_DENIED 0]
2015-04-09 20:10:23.834493 UTC - -1665145088[7f5bb6868a40]: nsHttpTransaction::ParseLine [Vary: Accept-Language]
2015-04-09 20:10:23.834498 UTC - -1665145088[7f5bb6868a40]: nsHttpTransaction::ParseLine [Content-Language: en]
2015-04-09 20:10:23.834502 UTC - -1665145088[7f5bb6868a40]: nsHttpTransaction::ParseLine [Proxy-Authenticate: NTLM]
2015-04-09 20:10:23.834507 UTC - -1665145088[7f5bb6868a40]: nsHttpTransaction::ParseLine [Proxy-Authenticate: Basic realm="Squid proxy-caching web server"]
2015-04-09 20:10:23.834512 UTC - -1665145088[7f5bb6868a40]: nsHttpTransaction::ParseLine [X-Cache: MISS from mozilla-Precision-T1700]
2015-04-09 20:10:23.834517 UTC - -1665145088[7f5bb6868a40]: nsHttpTransaction::ParseLine [X-Cache-Lookup: NONE from mozilla-Precision-T1700:3128]
2015-04-09 20:10:23.834522 UTC - -1665145088[7f5bb6868a40]: nsHttpTransaction::ParseLine [Via: 1.1 mozilla-Precision-T1700 (squid/3.3.8)]
2015-04-09 20:10:23.834526 UTC - -1665145088[7f5bb6868a40]: nsHttpTransaction::ParseLine [Connection: keep-alive]
2015-04-09 20:10:23.834531 UTC - -1665145088[7f5bb6868a40]: nsHttpTransaction::HandleContent [this=7f5b80d71400 count=3338]
2015-04-09 20:10:23.834538 UTC - -1665145088[7f5bb6868a40]: nsHttpTransaction::HandleContentStart [this=7f5b80d71400]

2015-04-09 20:10:23.834542 UTC - -1665145088[7f5bb6868a40]: http response [
2015-04-09 20:10:23.834552 UTC - -1665145088[7f5bb6868a40]:   HTTP/1.1 407 Proxy Authentication Required
2015-04-09 20:10:23.834555 UTC - -1665145088[7f5bb6868a40]:   Server: squid/3.3.8
2015-04-09 20:10:23.834559 UTC - -1665145088[7f5bb6868a40]:   Mime-Version: 1.0
2015-04-09 20:10:23.834562 UTC - -1665145088[7f5bb6868a40]:   Date: Thu, 09 Apr 2015 20:10:23 GMT
2015-04-09 20:10:23.834565 UTC - -1665145088[7f5bb6868a40]:   Content-Type: text/html
2015-04-09 20:10:23.834577 UTC - -1665145088[7f5bb6868a40]:   Content-Length: 3338
2015-04-09 20:10:23.834580 UTC - -1665145088[7f5bb6868a40]:   X-Squid-Error: ERR_CACHE_ACCESS_DENIED 0
2015-04-09 20:10:23.834584 UTC - -1665145088[7f5bb6868a40]:   Vary: Accept-Language
2015-04-09 20:10:23.834587 UTC - -1665145088[7f5bb6868a40]:   Content-Language: en
2015-04-09 20:10:23.834591 UTC - -1665145088[7f5bb6868a40]:   Proxy-Authenticate: NTLM
Basic realm="Squid proxy-caching web server"
2015-04-09 20:10:23.834594 UTC - -1665145088[7f5bb6868a40]:   X-Cache: MISS from mozilla-Precision-T1700
2015-04-09 20:10:23.834597 UTC - -1665145088[7f5bb6868a40]:   X-Cache-Lookup: NONE from mozilla-Precision-T1700:3128
2015-04-09 20:10:23.834601 UTC - -1665145088[7f5bb6868a40]:   Via: 1.1 mozilla-Precision-T1700 (squid/3.3.8)
2015-04-09 20:10:23.834604 UTC - -1665145088[7f5bb6868a40]:   Connection: keep-alive
2015-04-09 20:10:23.834607 UTC - -1665145088[7f5bb6868a40]: ]
2015-04-09 20:10:23.834610 UTC - -1665145088[7f5bb6868a40]: nsHttpConnection::OnHeadersAvailable [this=7f5b87a8a1d0 trans=7f5b80d71400 response-head=7f5b94bd6650]
2015-04-09 20:10:23.834615 UTC - -1665145088[7f5bb6868a40]: Connection can be reused [this=7f5b87a8a1d0 idle-timeout=115sec]
2015-04-09 20:10:23.834619 UTC - -1665145088[7f5bb6868a40]: proxy CONNECT failed! endtoendssl=1
2015-04-09 20:10:23.834624 UTC - -1665145088[7f5bb6868a40]: nsHttpTransaction::HandleContent [this=7f5b80d71400 count=3338 read=3338 mContentRead=3338 mContentLength=3338]
2015-04-09 20:10:23.834628 UTC - -1665145088[7f5bb6868a40]: nsHttpTransaction 7f5b80d71400 loadgroupci set to null in ReleaseBlockingTransaction() - was 7f5b81030a00
2015-04-09 20:10:23.834639 UTC - -1665145088[7f5bb6868a40]: nsHttpConnection::CloseTransaction[this=7f5b87a8a1d0 trans=7f5b80d71400 reason=80470002]
2015-04-09 20:10:23.834643 UTC - -1665145088[7f5bb6868a40]: nsHttpTransaction::Close [this=7f5b80d71400 reason=0]
2015-04-09 20:10:23.834648 UTC - -1665145088[7f5bb6868a40]: nsHttpConnectionMgr::ReclaimConnection [conn=7f5b87a8a1d0]
2015-04-09 20:10:23.834663 UTC - -1665145088[7f5bb6868a40]: nsHttpTransaction 7f5b80d71400 loadgroupci set to null in ReleaseBlockingTransaction() - was 0
2015-04-09 20:10:23.834678 UTC - -1665145088[7f5bb6868a40]: nsHttpConnectionMgr::OnMsgReclaimConnection [conn=7f5b87a8a1d0]
2015-04-09 20:10:23.834684 UTC - -1665145088[7f5bb6868a40]: nsHttpConnectionMgr::ConditionallyStopTimeoutTick armed=1 active=0
2015-04-09 20:10:23.834687 UTC - -1665145088[7f5bb6868a40]: nsHttpConnectionMgr::ConditionallyStopTimeoutTick stop==true
2015-04-09 20:10:23.834694 UTC - -1665145088[7f5bb6868a40]: nsHttpConnection::SetupSSL 7f5b87a8a1d0 caps=0x21 PS....self-repair.mozilla.org:443 (http:192.168.0.3:3128)
2015-04-09 20:10:23.834706 UTC - -1665145088[7f5bb6868a40]:   adding connection to idle list
2015-04-09 20:10:23.834710 UTC - -1665145088[7f5bb6868a40]: nsHttpConnection::BeginIdleMonitoring [this=7f5b87a8a1d0]
2015-04-09 20:10:23.834713 UTC - -1665145088[7f5bb6868a40]: Entering Idle Monitoring Mode [this=7f5b87a8a1d0]
2015-04-09 20:10:23.834718 UTC - -1665145088[7f5bb6868a40]: nsHttpConnectionMgr::OnMsgProcessPendingQ [ci=PS....self-repair.mozilla.org:443 (http:192.168.0.3:3128)]
2015-04-09 20:10:23.834722 UTC - -1665145088[7f5bb6868a40]: nsHttpConnectionMgr::ProcessPendingQForEntry [ci=PS....self-repair.mozilla.org:443 (http:192.168.0.3:3128) ent=7f5b80d9af00 active=0 idle=1 queued=0]
2015-04-09 20:10:23.834729 UTC - -1665145088[7f5bb6868a40]: nsHttpConnectionMgr::ProcessPendingQForEntry [ci=PS....safebrowsing.google.com:443 (http:192.168.0.3:3128) ent=7f5b80feec80 active=0 idle=1 queued=0]
2015-04-09 20:10:23.834733 UTC - -1665145088[7f5bb6868a40]: nsHttpConnectionMgr::ProcessPendingQForEntry [ci=PS....self-repair.mozilla.org:443 (http:192.168.0.3:3128) ent=7f5b80d9af00 active=0 idle=1 queued=0]
2015-04-09 20:10:23.836871 UTC - -1211422848[7f5bb68684a0]: sending progress and status notification [this=7f5b80dea800 status=804b000a progress=0/0]
2015-04-09 20:10:23.837187 UTC - -1211422848[7f5bb68684a0]: nsHttpChannel::Resume [this=7f5b80dea800]
2015-04-09 20:10:23.837227 UTC - -1211422848[7f5bb68684a0]: nsHttpChannel::OnStartRequest [this=7f5b80dea800 request=7f5b80d69200 status=0]
2015-04-09 20:10:23.837233 UTC - -1211422848[7f5bb68684a0]: nsHttpChannel::ProcessResponse [this=7f5b80dea800 httpStatus=407]
2015-04-09 20:10:23.837246 UTC - -1211422848[7f5bb68684a0]: nsHttpHandler::NotifyObservers [chan=80dea850 event="http-on-examine-response"]
2015-04-09 20:10:23.837252 UTC - -1211422848[7f5bb68684a0]: nsHttpChannelAuthProvider::ProcessAuthentication [this=7f5b811a4c60 channel=7f5b80deac58 code=407 SSLConnectFailed=1]
2015-04-09 20:10:23.837257 UTC - -1211422848[7f5bb68684a0]: nsHttpChannelAuthProvider::PrepareForAuthentication [this=7f5b811a4c60 channel=7f5b80deac58]
2015-04-09 20:10:23.837263 UTC - -1211422848[7f5bb68684a0]: nsHttpChannelAuthProvider::GetAuthenticator [this=7f5b811a4c60 channel=7f5b80deac58]
2015-04-09 20:10:23.837271 UTC - -1211422848[7f5bb68684a0]: nsHttpChannelAuthProvider::GetCredentialsForChallenge [this=7f5b811a4c60 channel=7f5b80deac58 proxyAuth=1 challenges=NTLM]
2015-04-09 20:10:23.837280 UTC - -1211422848[7f5bb68684a0]: nsHttpAuthCache::GetAuthEntryForDomain [key=http://192.168.0.3:3128 realm=]
2015-04-09 20:10:23.837286 UTC - -1211422848[7f5bb68684a0]: nsHttpNTLMAuth::ChallengeReceived [ss=0 cs=0]
2015-04-09 20:10:23.837293 UTC - -1211422848[7f5bb68684a0]: Force use of generic ntlm auth module: 0
2015-04-09 20:10:23.837297 UTC - -1211422848[7f5bb68684a0]: Default credentials allowed for proxy: 1
2015-04-09 20:10:23.843603 UTC - -1211422848[7f5bb68684a0]: Native sys-ntlm auth module not found.
2015-04-09 20:10:23.843636 UTC - -1211422848[7f5bb68684a0]: Trying to fall back on internal ntlm auth.
2015-04-09 20:10:23.843661 UTC - -1211422848[7f5bb68684a0]:   identity invalid = 1
2015-04-09 20:10:23.843671 UTC - -1211422848[7f5bb68684a0]: nsHttpChannelAuthProvider::PromptForIdentity [this=7f5b811a4c60 channel=7f5b80deac58]
2015-04-09 20:10:23.894932 UTC - -1211422848[7f5bb68684a0]: Suspending the transaction, asynchronously prompting for credentials
2015-04-09 20:10:23.918676 UTC - -1211422848[7f5bb68684a0]: nsHttpChannelAuthProvider::OnAuthCancelled [this=7f5b811a4c60 channel=7f5b80deac58]
2015-04-09 20:10:23.918696 UTC - -1211422848[7f5bb68684a0]: nsHttpChannelAuthProvider::GetAuthenticator [this=7f5b811a4c60 channel=7f5b80deac58]
2015-04-09 20:10:23.918705 UTC - -1211422848[7f5bb68684a0]: nsHttpChannelAuthProvider::GetCredentialsForChallenge [this=7f5b811a4c60 channel=7f5b80deac58 proxyAuth=1 challenges=Basic realm="Squid proxy-caching web server"]
2015-04-09 20:10:23.918720 UTC - -1211422848[7f5bb68684a0]: nsHttpAuthCache::GetAuthEntryForDomain [key=http://192.168.0.3:3128 realm=Squid proxy-caching web server]
2015-04-09 20:10:23.918727 UTC - -1211422848[7f5bb68684a0]:   identity invalid = 1
2015-04-09 20:10:23.918732 UTC - -1211422848[7f5bb68684a0]: nsHttpChannelAuthProvider::PromptForIdentity [this=7f5b811a4c60 channel=7f5b80deac58]


in firefox 36 after sys-ntlm an error is return and the firefox falls back to basic. 
In firefox 37, we always try a generic authentication (the line "2015-04-09 20:10:23.843636 UTC - -1211422848[7f5bb68684a0]: Trying to fall back on internal ntlm auth."  is from the part of the code that is trying generic authentication).
Than we prompt user for identity. On that prompt I clicked cancel (2015-04-09 20:10:23.918676 UTC - -1211422848[7f5bb68684a0]: nsHttpChannelAuthProvider::OnAuthCancelled [this=7f5b811a4c60 channel=7f5b80deac58]) and now we fall back to basic authenrication...

2015-04-09 20:10:23.918696 UTC - -1211422848[7f5bb68684a0]: nsHttpChannelAuthProvider::GetAuthenticator [this=7f5b811a4c60 channel=7f5b80deac58]
2015-04-09 20:10:23.918705 UTC - -1211422848[7f5bb68684a0]: nsHttpChannelAuthProvider::GetCredentialsForChallenge [this=7f5b811a4c60 channel=7f5b80deac58 proxyAuth=1 challenges=Basic realm="Squid proxy-caching web server"]


In the log from Tommy: 

2015-04-02 12:30:06.327078 UTC - 2074251648[100563110]: Trying to fall back on internal ntlm auth.
2015-04-02 12:30:06.327465 UTC - 2074251648[100563110]:   identity invalid = 1
2015-04-02 12:30:06.327473 UTC - 2074251648[100563110]: nsHttpChannelAuthProvider::PromptForIdentity [this=11d2085c0 channel=11ccf2430]
2015-04-02 12:30:06.364255 UTC - 2074251648[100563110]: Suspending the transaction, asynchronously prompting for credentials
2015-04-02 12:30:06.364275 UTC - 2074251648[100563110]: nsInputStreamPump::Suspend [this=11d274bc0]
2015-04-02 12:30:06.371264 UTC - 2074251648[100563110]: nsHttpChannelAuthProvider::OnAuthAvailable [this=11d2085c0 channel=11ccf2430]

If Tommy is not clicking ok something else is filling it automatically....(I do not know part of the code with user prompts ... I will need to take a look at it, or if somebody have a quick answer ...)
Have you try to use a clean profile?

Sorry if you have already tried it and I miss it,
Flags: needinfo?(tommy)
FYI: Bug 548925 is a request to have more control over what auth methods are supported, like the request here to allow NTLM to be turned off totally.

I'm still lost as to why the proxy isn't accepting our NTLM login.  I would rather address this issue from that side, if at all possible.
Flags: needinfo?(mcmanus)
I am getting an authentication required to access an internal website in my company. Anyway to fix this ? I won't authenticate my domain credentials.
See Also: → 1150438
Whiteboard: [necko-backlog][ntlm]
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: -- → P1
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: P1 → P3
Severity: normal → S3

Moving bug to Core/Networking: Proxy.

Component: Networking → Networking: Proxy

A needinfo is requested from the reporter, however, the reporter is inactive on Bugzilla. Given that the bug is still UNCONFIRMED, closing the bug as incomplete.

For more information, please visit BugBot documentation.

Status: UNCONFIRMED → RESOLVED
Closed: 2 months ago
Flags: needinfo?(tommy)
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.