Seems more a proxy issue than an auth issue - Chrome doesn't even know it needs auth until after it connects, and sounds like the expectation is Chrome shouldn't be connecting in the first place.

This sounds like it could be our proxy fallback logic - if a non-mandatory proxy fails and direct HTTP connections work, we'll mark the proxy as bad and use direct connection.

Could you get us an about:net-export log of this happening?  That would at least let us verify if the proxy is marked as bad.  Instructions:  https://www.chromium.org/for-testers/providing-network-details

comment #0 already contains a log.

The proxy server returns an NTLM challenge in response to requests on go.eu.bbelements.com. So the problem is that Chrome is unable to authenticate to the proxy server.

The log shows an attempt made using some implied credentials. Could be a previously cached credential, or credentials retrieved from Windows (not familiar enough with this code to tell).

If this is working on other browsers I would expect it is because the authentication step is completing, and only then is the request failed by the proxy server.

So if the intent is to fail the request somehow, that order of events can't happen until the proxy auth completes and it subsequently returns some other failure.

RE: 1,2,3 No, it's not falling back and proxy is not marked as "bad" we can see it in net-internals in https://drive.google.com/open?id=1SS_XbULirXHVh95Qt433kvTzRRYeC8M8

Re: #4 
Maybe we can review our logic/order of evens and find out if we intentionally are doing that or it requires revision?

Customer is constantly asking for news or/and updates

++David, need your expertise in proxy and NTLM.
David, can you please take a look?

No, I do not have expertise on proxy and NTLM. Additionally I'm out for a bit. This should stay in the network bug triage queue.

Not following what the issue is here - we send a CONNECT request to the proxy, it sends a 407 and an NTLM challenge.  We send credentials, the proxy then response with the next round of NTLM (?).  We then send another tunnel request, without authentication information, and then the server hangs up on us.

I guess we conclude the hang up meant the credentials were bad and retry for some reason?  Our proxy logic is a bit of a mess, but I think this is also unusual behavior for a proxy server.

Hi,
this problem have two parts. All situations are “With authentication” and proxy setting "Proxy have disabled replay HTTPS error mesage".

First situation - the main URL is blocked
Any browser cannot load page. Only Chorme ask over and over for credentional.

Exemple videos
Chrome - main URL block.mp4
IE - main URL block.mp4

Second situation - the main URL is OK, but some another URL with content is blocked 
Like reported advertisement URL "go.eu.bbelements.com"at https://www.digitalnitelevize.cz/
Main site is loaded at every browser, but Chrome sometimes make blank site between refreshing authentication request.

Exemple videos
Chrome - part URL block.mp4
IE - part URL block.mp4

PS: Every browser use SSO, then Chrome will request for credential. It doesn't matter if I enter valid login information or not.

Deleted: videos.zip 7.1 MB

videos.zip 7.1 MB Download

mmenke@
Please check the provided information from the customer and let us know if you require additional information regarding this case.

[asanka]:  Thoughts?  From my earlier analysis, looks like the proxy hangs up after multi-round auth, rather than sending a 403, and we decide we should retry.

[Assigning to Asanka since the question is directed at him. Also adding Brandon to provide an example of chrome issue from the field]

#13: Yeah, that's pretty much what's happening.

Since the connection was dropped, Chrome attempts to retry using the same HttpAuthController. The latter has already consumed the ambient identity. The next thing it tries is explicit credentials. Hence the prompt.

Ideally, Chrome shouldn't retry at this stage since the connection was dropped in the middle of a handshake. I.e. should treat it as an error.

We do allow the connection to drop between the initial challenge and the first client response. The latter is important functionality to preserve.

I agree that the server behavior is odd. The correct behavior is to return a 403. Terminating connections without completing the response, even when do so cleanly, is indistinguishable from legitimate network failures.

Hi Team, do we have any updates on this issue? Customer also provided additional information on the reason why they have configured their proxy to not respond with an error code, and it seems it’s because they don’t have the option to respond with a self-signed certificate:

*About behavior proxy.....*
We have two options to set behavior proxy
*pA*)
When I open HTTPS website at Chrome and proxy Deny this URL, browser will
receive HTTPS error message with self-signet certificate.
*pB*)
When I open HTTPS website at Chrome and proxy Deny this URL, browser will
not receive any HTTPS error message. Proxy have disabled replay HTTPS error
message.

We configure the proxy for behavior (*pB*) because, we don't have
permission to implement trusted CA at proxy or make trust self-signed CA at
client computers.
And we do not want our clients to see error messages of INVALID CERTIFICATE.

Acknowledged.

#16: Hmm. Doesn't returning a 403 with no content result in a browser generated error page without the issue you mention?

#18: It seems that it would return "NET::ERR_CERT_AUTHORITY_INVALID". Other behavior details are also here: https://docs.google.com/document/d/1FC7djuPu7fLbFpjpJwSrpitsPd0-Mb-IZGJ76DXMWQ0/. Let me know if other tests or information is needed.

The error message is one of the things that the customer is trying to avoid though. One of the main concerns is that fact that, with the current configuration, only Chrome continues to ask for authentication, while other browsers behave as desired (Non-filtered content is loaded and no authentication is requested). Does this look like something that can be changed for Chrome?

Yeah. I'm working on a patch to disable retrying under these circumstances.

Thanks, this is great news. We'll be looking forward to it.

Hi Team, do we have any updates on this?

Hello @asanka, do you happen to have an update or ETA for this? Because of this issue, the deployment of a required proxy solution for ~12,000 users has been stalled.

Friendly bump on this, please let us know if there are any updates.

Apologies for not updating this issue for a while. I'm planning on getting this done this week.

Hi guys, any updates that we can provide to the customer?

Hi Asanka,

As this issue is impacting heavily ("the deployment of a required proxy solution for ~12,000 users has been stalled") one of our strategic Enterprise customers, could you please report your progress on a regular basis?

Thank you for following this issue and working on the fix.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/bc3f8f6f5e6622df19995c1265e8abfc8c6b7b46

commit bc3f8f6f5e6622df19995c1265e8abfc8c6b7b46
Author: Asanka Herath <asanka@chromium.org>
Date: Fri Nov 16 23:08:30 2018

[net/auth] Reuse identity source if the identity was not invalidated.

Under several circumstances, the network transaction or the
HttpAuthController may invalidate an authentication handler with the
intention of retrying the same transaction. During this process, any
sources of identity that were consumed should be made available for
reuse. Otherwise the behavior of the retry operation could end up being
wildly different from the original transaction.

This is particularly pronounced when dealing with HttpAuthHandler
implementations that support both ambient and explicit credentials. For
those, the retry attempt will switch from ambient to explicit identity.
This CL updates HttpAuthController to restore the identity source such
that the retry correctly attempts the ambient identity again.

Bug:  857228 
Change-Id: If4a9cfa30aa0ddb996a4856ae282c7f7358dce7b
Reviewed-on: https://chromium-review.googlesource.com/c/1329902
Reviewed-by: Matt Menke <mmenke@chromium.org>
Commit-Queue: Asanka Herath <asanka@chromium.org>
Cr-Commit-Position: refs/heads/master@{#609015}
[modify] https://crrev.com/bc3f8f6f5e6622df19995c1265e8abfc8c6b7b46/net/http/http_auth_controller.cc
[modify] https://crrev.com/bc3f8f6f5e6622df19995c1265e8abfc8c6b7b46/net/http/http_auth_controller.h
[modify] https://crrev.com/bc3f8f6f5e6622df19995c1265e8abfc8c6b7b46/net/http/http_network_transaction_unittest.cc
[modify] https://crrev.com/bc3f8f6f5e6622df19995c1265e8abfc8c6b7b46/net/http/http_proxy_client_socket_wrapper.cc

This change is now in 72.0.3613.0 and later (Canary).

The change in Chrome's behavior is a compromise between the behavior requested in this issue and what's needed for resiliency in other environments.

The key problem is that a connection closure during the authentication handshake cannot be interpreted as an intentional signal meaning the target is inaccessible. Due to middlebox interference Chrome can't assume that a TCP connection termination in the absence of any other error is intentional either. For these reasons, Chrome retries an interrupted authentication handshake during tunnel establishment via an HTTP/S proxy. There was a bug where this retry mechanism failed to reuse the ambient identity. The change in #31 addresses this.

The new behavior is that Chrome retries an interrupted authentication handshake *once* if it occurs during tunnel establishment through a proxy. There's no additional prompt for the retry. If the new attempt also fails, Chrome gives up and surfaces the error.

Unfortunately there's no standardized way for a proxy server to indicate that the target resource is inaccessible during an HTTP CONNECT. A common mechanism in use today by several proxy vendors is to respond with an HTTP 403 or an HTTP 5xx after any optional authentication handshake has taken place.

I'd be interested in knowing which software implements this behavior (connection termination during auth handshake) and how prevalent it is. If possible we'd like to reach out to the vendor and encourage them to move to a de-facto standard mechanism instead.