Reported externally on Firefox 54 via mozilla-symantec-discuss forum. Observed in a PCAP log received via the same forum. I don't have a log for a session were this issue has happened hence it's hard to say what happens exactly. From what I know so far it seems like the proxy closes the connection after sending back Type2 message which is illegal and quite illogical, but our reaction to it seems unexpected. We restart the authentication on a new connection and try to send the Type3 message - that should never happen, hence the uncertainty and marking UNCONFIRMED. It's impossible to send Type3 message when communicating with the proxy for the first time (new connection) as a cached credential (we don't cache the request header, we only cache credentials when available and generate headers using those creds.) In case of Windows client SSO via SSPI we don't cache anything, as there is actually nothing to cache, AFAIK - the SSPI module does the negotiation internally w/o asking for credentials. Note that the negotiation dance happens under the hood of a single HTTP request and the module is held as a continuation state inside nsHttpChannelAuthProvider (1-1 rel with a channel) hence it can't leak between different requests. Next step: obtain more detailed logs.

Closing for lack of response in the "[mozilla-symantec-discuss] Strange Mozilla Behaviour with Symantec ProxySG and Authentication" thread.

I've obtained logs from Symantec that clearly demonstrate the issue and I was capable of identifying the cause. The situation is reproducible for the following sequence of responses: GET https://foo -> 407 Proxy-Authenticate: NEGOTIATE, NTLM, BASIC GET https://foo, Proxy-Authorization: NEGOTIATE type1 -> 407 Proxy-Authenticate: NEGOTIATE type2 GET https://foo, Proxy-Authorization: NEGOTIATE type3 -> 401 WWW-Authenticate: Basic (from the server) GET https://foo, Proxy-Authorization: NEGOTIATE type3 (the bug), Authorization: Basic The reason we resend the type3 message is because in nsHttpChannelAuthProvider::PrepareForAuthentication we incorrectly create the authenticator instance using the raw (upper case) NEGOTIATE proxy challenge as a type. The correct way is to lower case it or use an existing method that does it correctly. Patch comes.

(missed something)

Pushed by csabou@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/10c2d7ed3aaf yBug 1423278 - Correctly instantiate proxy authenticator with a lowercase schema, r=jduell

https://hg.mozilla.org/mozilla-central/rev/10c2d7ed3aaf (landed 21 hours ago)

Comment on attachment 9005025 [details] [diff] [review] v1 Approval Request Comment [Feature/Bug causing the regression]: bug 278885 (fixed 2005) [User impact if declined]: connection dropping under some circumstances, inability to load web pages [Is this code covered by automated tests?]: I'm afraid not [Has the fix been verified in Nightly?]: not yet [Needs manual test from QE? If yes, steps to reproduce]: the setup is not simple to build, the issue is so trivial that an automated test is IMO not even needed [List of other uplifts needed for the feature/fix]: none [Is the change risky?]: no [Why is the change risky/not risky?]: this only changes a contract id for getting an authenticator to be correctly built using the lower case string of the proxy auth schema [String changes made/needed]: none [Approval Request Comment] If this is not a sec:{high,crit} bug, please state case for ESR consideration: This bug makes NTLM/Negotiate proxies mainly used in corporate (ESR audience) environments under some circumstances drop connections. User impact if declined: It's manifesting as inability of the browser to load web pages. Fix Landed on Version: 63 Risk to taking this patch (and alternatives if risky): Not risky. String or UUID changes made by this patch: None

Comment on attachment 9005025 [details] [diff] [review] v1 63 is already on Beta and 62 is on release. Is this something you'd want us to dot release for?

(In reply to Ryan VanderMeulen [:RyanVM] from comment #9) > Comment on attachment 9005025 [details] [diff] [review] > v1 > > 63 is already on Beta and 62 is on release. Is this something you'd want us > to dot release for? No. What I think is way more important is to get this to ESR, all branches we support, because the audience of ESR is likely way more affected than regular users in non-corporate envs. Thanks.

Comment on attachment 9005025 [details] [diff] [review] v1 Fixes connectivity issues for users on NTLM domains. Approved for ESR 60.3.