Thanks for the report, could you please share the url tried to reproduce the issue and help triage further.

I am behind a blue coat proxy/firewall/filter in a corporate network, so you will not be able to use that same URL to provoke the error. The URL is something like this:

https://<company>bluecoat4:4443/?cfru=<base64-encoded target URL>

I can ping <company>bluecoat4, and it is being resolved as <company>bluecoat4.something.company.com

How do I get to this URL?
I am redirected to this page (with an HTTP 302 error, I guess) when I open the target URL in Chrome with unmodified user agent, or when using wget with the Chrome user agent. 

(Fyi, I can open the original target URL in Internet Explorer without any redirection just fine; I can open it with wget with no user agent, too; and I can open it in Chrome with a manipulated user agent, using "Sofari" instead of "Safari".)

Yeah, this can happen if authentication fails due to lack of credentials. 

The error should mention that authentication was required. The message should also distinguish between a proxy auth failure and a server auth failure since those are likely to point at different culprits. E.g. a proxy auth failure could result in this page while attempting to visit https://google.com. In this case, the fault is a failure to authenticate the client to the proxy, not the server.

Given that the error we surface doesn't distinguish between proxy and server auth, we should consider splitting ERR_INVALID_AUTH_CREDENTIALS and related error codes so that we tell proxy authentication errors and server authentication errors.

We could choose to introduce an ambiguous error message that tells the user that Chrome couldn't authenticate against something without specifying whether the target was a proxy or a server.

+Julia: FYI. Since this pertains to error pages. Also do you know which metrics we use to determine whether a new error page is warranted for cases like this?

Thanks for your feedback. Just to clarify one thing (in case it matters): I called the thing that blocks me "proxy", but from a client point of view, I do not see a proxy at all. I do not have a proxy configured in "Internet Options" or in any Chrome extension; and I can reproduce the redirect in wget by changing just the user agent string. The fact that https traffic is never redirected indicates to me that traffic is redirected using a packet-based filter. I just wanted to clarify that in case the distinction between proxy and server authentication is an important one.

Yup. I was addressing the Chrome-side issue, which is that the error message is incorrect. The distinguishing between proxy and server authentication is important since it's possible that the two represent different organizations/entities/authorities.

The fact that the authentication challenge is presented to Chrome based on a UA string sounds like a bug given that it's possible to bypass the authentication requirement by using a malformed UA string. I'd take that up with your firewall product support.

Just a note to mr.berker@ that you might also be running into  issue 648366  which was caused by KB3189866 on Windows 10. This is tangential to the issue of the error message being incorrect.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

[edwardjung]:  Not sure if this has since been changed, just going through old bugs.

The text is still the same using the generic text, it looks like we still don't differentiate between the proxy / server auth error.

We could specify dedicated strings but it's extremely low in the number of users who encounter this.