Oh and MS16-110 is supposed to only affect NTLM SSO.

Can you confirm that single-sign-on isn't supposed to work? And that the expected behavior should've been to prompt the user for explicit credentials?

In that case we should consider this a Chrome issue since Chrome should've used explicit credentials as a fall back.

Yes I can confirm that SSO is not supposed to work.  The way our system
works is that the first attempt of the day should ask you for creds then
each attempt after that should be automatic.  But the first attempt is not
asking for creds and is just erroring out.

Thanks,
Melissa Long
Trading Technologies, Inc

If you still have a machine where KB3189866 is absent and the login is working correctly, could you get me a net-internals log of a successful login attempt? I want to confirm a hunch that KB3189866 is changing the behavior when there are no credentials available in your configuration.

I can confirm it is KB3189866 causing the problem as I did a restore to check, however I can't revert back anymore.

here you go.

Thanks,
Melissa Long
Trading Technologies, Inc

(attachment missing?)

I have attached it here.

Deleted: net-internals-log (1).json 1.3 MB

net-internals-log (1).json 1.3 MB View Download

Adding Milestone for the filed chrome version , can anyone confirm whether this is a release blocker.

Also bumping priority.

This is not a release blocker in the sense that it's not a regression. This is an interaction with Chrome's age old behavior and Window's recently introduced behavior.

https://codereview.chromium.org/2382293004

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

commit c930761972fa8611069d0e55e3f45dd0c56c2d54
Author: asanka <asanka@chromium.org>
Date: Mon Oct 03 15:46:02 2016

[net] clang-format HttpNetworkTransactionTest.GenerateAuthToken test.

This is a pretty big test with a lot of test cases. clang-format pretty
much reformats the entire test beyond recognition. Subsequent patches
that may touch this test will be unreviewable if they also include the
formatting changes. Uploading the formatting changes separately.

BUG= 648366 

Review-Url: https://codereview.chromium.org/2385883002
Cr-Commit-Position: refs/heads/master@{#422429}

[modify] https://crrev.com/c930761972fa8611069d0e55e3f45dd0c56c2d54/net/http/http_network_transaction_unittest.cc

Is there a merge required for M54? If yes, please verify in canary and request a merge soon.

Not sure who has hardware/infrastructure to test this. Considering that this is related to proxy auth (which is big enterprise usecase) and its a new behavior, I think this would be looked on as a regression by users, so flagging it as release block stable to raise visibility.

I have the chance to test any available solution.
I have the same exact problem and reported the issue in several posts:
https://productforums.google.com/forum/#!topic/chrome/fkGPl5hXpVA;context-place=topicsearchin/chrome/err_invalid_auth_credentials
https://productforums.google.com/forum/#!topic/chrome/ZN4JpSF-xWk;context-place=forum/chrome
https://answers.microsoft.com/en-us/windows/forum/windows_10-networking/kb3189866-kb3193494-and-kb3194496-cause-problem/75117def-9b2e-4434-9e8c-348f4108ed7a

My case is:
- client with squid firewall (don't know version, it's up to system BU)
- my laptop IS NOT a domain computer
- I have windows 10 x64, KB3189866 NOT installed, KB3193494 NOT installed, KB3194496 installed (--> windows version 1607, build 14393.222)

Thanks for the update in #37. The fix is available in latest canary - 	56.0.2886.0 paolo.franceschini@  Will it be possible for you to verify the fix?

Note about release: 

We are planning a STABLE RC cut tomorrow(10/11), Tuesday at 4.00 PM PST.So please request a merge if all looks good and merge before noon.We will not be taking any patches after noon.

Unfortunately the fix in https://codereview.chromium.org/2382293004 is still in review. 

Just a few questions ligim...@chromium.org.
Where can I find the update?
Will it go over my current chrome installation (Version 53.0.2785.143 m - 64-bit) or will install side by side? I'm asking because my current chrome is highly customized with settings and extensions I use by the client.

Thanx

You can install chrome canary - https://www.google.com/chrome/browser/canary.html.

This will be a side by side installation, so you don't need to disturb the current user data.

Thanks for offering help.

ligimole:  Per Asanka's comment above, the issue is not yet fixed on Canary.

Yes, confirmed patch is not landed.

IMPORTANT : 
We are planning M54 STABLE RC cut today (10/11), Tuesday at 4.00 PM PST. So please have the fix landed and merged to branch ASAP (considering the comment #35 since verification is not possible unless its deployed). 

We will not be taking any merges after 3.00 PM PST !

It's 10 PM now in Italy (UTC+2.00) and I'm not by the client.
I can test tomorrow morning, starting from 10:00 AM.

Hope it's not too late

This fix also needs to be merged to M55. So adding "M-55" label.

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

commit e2257db89c38e2846d27a6de41a1ed4804ee5cab
Author: asanka <asanka@chromium.org>
Date: Tue Oct 11 22:03:16 2016

[net/auth] Don't abort network transaction over non-permanent auth errors.

A multi-round authentication handshake may break partway through with an
error that indicates that the credentials used were invalid. With GSSAPI
we've seen this come up when the underlying library attempted to
authenticate against an endpoint even though no valid credentials were
available to finish the handshake. On Windows, this is now possible
since KB3189866.

Due to the fact that the underlying libraries attempt to start the
authentication handshake, the HttpNetworkTransaction proceeds past the
point where the HttpAuthController accepts the challenge and picks an
identity to use for the handshake. However, when the time comes to
generate a token, which happens just prior to sending the next HTTP
request, the HttpAuthController fails the operation with an
ERR_INVALID_AUTH_CREDENTIALS error. The state machine can't proceed past
this error and the user ends up looking at an error page.

e.g.:

  C->S : GET something

  S->C : HTTP/1.1 401 You shall not pass
         WWW-Authenticate: Negotiate

  C->[underlying authentication library, hereafter called UAL] :
         "Can you authenticate to example.com?"

  [UAL]->C: "Sure thing. Here's a token to get started : [token1]"

  C->S : GET something
         Authorization: Negotiate [token1]

  S->C : HTTP/1.1 401 Need moar authentication
         WWW-Authenticate: Negotiate [token2]

  C->[UAL]: "example.com gave us [token2]. What should we do now?"

  [UAL]->C: "LOL. Who knows? Look a squirrel!"

  C: ...

  C: Shows ERR_INVALID_AUTH_CREDENTIALS to the user.

This should be considered a permanent error if there is actually no
other way to proceed. However, if there are other authentication schemes
to try, or if the initial authentication attempt was made using ambient
credentials and the scheme supports explicit credentials, then those
should be attempted next.

This CL changes the response of the network stack at the final step to
restart the network transaction by sending a request with no
Authorization header. This signals to the server that the client is
restarting the authentication handshake. It can then start over at which
point the client can attempt to use a different identity or a different
authentication scheme to proceed.

R=mmenke
BUG= 648366 

Review-Url: https://codereview.chromium.org/2382293004
Cr-Commit-Position: refs/heads/master@{#424563}

[modify] https://crrev.com/e2257db89c38e2846d27a6de41a1ed4804ee5cab/net/http/http_auth_controller.cc
[modify] https://crrev.com/e2257db89c38e2846d27a6de41a1ed4804ee5cab/net/http/http_auth_controller.h
[modify] https://crrev.com/e2257db89c38e2846d27a6de41a1ed4804ee5cab/net/http/http_auth_controller_unittest.cc
[modify] https://crrev.com/e2257db89c38e2846d27a6de41a1ed4804ee5cab/net/http/http_network_transaction_unittest.cc

Per discussion we decided to not take this change for M54 until next week, to let it bake in canary.  Please don't merge until after 5pm.

Hi

as per comment #37

I downloaded the last Canary from here: https://www.google.com/chrome/browser/canary.html

It installed Version 56.0.2888.0 canary (64bit)

I do not receive ERR_INVALID_AUTH_CREDENTIALS error but I cannot navigate as well.
Not the error is ERR_INVALID_HANDLE

Please let me know If I can give you further information and how.

Best regards
Paolo

I forgot to mention that for all sites/domains included in in proxy exclusion I have NO PROBLEM, Chrome show the popup requesting for domain credentials.

Ciao
P.

#48: Could you send us a net-internals log for the ERR_INVALID_HANDLE case? It seems this error condition isn't trivially reproducible.

Instructions for getting a net-internals log can be found in https://sites.google.com/a/chromium.org/dev/for-testers/providing-network-details

#50: you can find the report attached.

Please, only a specification. Today I'm not by my client, but I'm connected through OpenVPN.
I set the proxy in IE/Windows and, as expected, IE7 and Edge are working (they ask me for credentials), while Canary gives me the same error it gave me as reported in comment #48.

On my side the behaviour is the apparently the same, but it's better if you know my current settings in case you find strange info in the report.

Ciao
P.

Deleted: net-internals-log.json 933 KB

net-internals-log.json 933 KB View Download

I can confirm, latest Canary Build i get this error now:

ERR_INVALID_HANDLE

Any news?

asanka@ - Ping! As per comment #52, reporter has provided the required details for investigation. Could you please take a look in to it.

Thanks!

I came here through related Issue 647254 and I can confirm that Version 56.0.2891.0 canary (64-bit) has fixed the problem for me. No more ERR_INVALID_AUTH_CREDENTIALS in Canary (and I personally don't get ERR_INVALID_HANDLE, either).

Version 54.0.2840.59 m (64-bit) still has it, but I don't care because I can just logon (kind of) by opening any website in Canary, and the proxy/firewall thing that we have recognizes my stable Chrome for the rest of the day.

asanka/mmenke@ can we consider merging the CL- https://codereview.chromium.org/2382293004 ? Seems to be fixed in canary as per #57.

#57 is the intended effect, but I'm still concerned about the ERR_INVALID_HANDLE case. We can merge on the basis that the effect of the CL is strictly equal or better than what it was before. I.e. some subset of users will find that the issue is resolved, while others who were experiencing one error before will see another error now.

I've tried to reproduce the issue in our test lab, but failed. I'm going to work on this today and tomorrow and hopefully we'll find out what's really happening and have a concrete fix.

TL;DR: I'm OK with merging the change in #46, but I don't consider this issue fixed.

@asanka
in there's any other info I can provide, or log or anything else that could be helpful, please, feel free to ask

P.

The same version Version 56.0.2891.0 (same as yesterday, that is) is giving me ERR_INVALID_HANDLE today, too.

Let's merge #46 since Stable is happening soon, and we can fix this for the remaining users in M55.

#61: Do you mean you are seeing ERR_INVALID_HANDLE with 56.0.2891.0 now?

(whoops. Merge request was supposed to be contingent on whether the reporter is redacting their verification.)

[Automated comment] Request affecting a post-stable build (M54), manual review required.

#63 I did see ERR_INVALID_HANDLE with 56.0.2891.0 this morning, yes. After this, I was able to be logged in by faking my user agent (long story, Issue 647254), so I expect to be able to reproduce it only tomorrow.

Thanks!  Approved for 54

Asanka/ Richard, Wondering whether we can log a separate issue for tracking ERR_INVALID_HANDLE?

I am having the ERR_INVALID_HANDLE error now:

56.0.2895.0 canary (64-bit)

We are planning to cut stable RC @ 4.00 PM today and this is the only blocker which needed immediate action. Asanka, please prioritize. 
Would you like to merge CL which fixes  ERR_INVALID_AUTH_CREDENTIALS and log another bug for tracking ERR_INVALID_HANDLE ?

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

commit a3156ef390f3d8b4be451efd91ff4ce4897c8ef6
Author: Asanka Herath <asanka@chromium.org>
Date: Wed Oct 19 18:02:04 2016

[Merge-M54] [net] clang-format HttpNetworkTransactionTest.GenerateAuthToken test.

This is a pretty big test with a lot of test cases. clang-format pretty
much reformats the entire test beyond recognition. Subsequent patches
that may touch this test will be unreviewable if they also include the
formatting changes. Uploading the formatting changes separately.

BUG= 648366 

Review-Url: https://codereview.chromium.org/2385883002
Cr-Commit-Position: refs/heads/master@{#422429}
(cherry picked from commit c930761972fa8611069d0e55e3f45dd0c56c2d54)

Review URL: https://codereview.chromium.org/2431193004 .

Cr-Commit-Position: refs/branch-heads/2840@{#757}
Cr-Branched-From: 1ae106dbab4bddd85132d5b75c670794311f4c57-refs/heads/master@{#414607}

[modify] https://crrev.com/a3156ef390f3d8b4be451efd91ff4ce4897c8ef6/net/http/http_network_transaction_unittest.cc

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

commit 4a2c7f5c92f114f0fbab7d8a5afe611b243fa286
Author: Asanka Herath <asanka@chromium.org>
Date: Wed Oct 19 18:08:23 2016

[Merge-54][net/auth] Don't abort network transaction over non-permanent auth errors.

A multi-round authentication handshake may break partway through with an
error that indicates that the credentials used were invalid. With GSSAPI
we've seen this come up when the underlying library attempted to
authenticate against an endpoint even though no valid credentials were
available to finish the handshake. On Windows, this is now possible
since KB3189866.

Due to the fact that the underlying libraries attempt to start the
authentication handshake, the HttpNetworkTransaction proceeds past the
point where the HttpAuthController accepts the challenge and picks an
identity to use for the handshake. However, when the time comes to
generate a token, which happens just prior to sending the next HTTP
request, the HttpAuthController fails the operation with an
ERR_INVALID_AUTH_CREDENTIALS error. The state machine can't proceed past
this error and the user ends up looking at an error page.

e.g.:

  C->S : GET something

  S->C : HTTP/1.1 401 You shall not pass
         WWW-Authenticate: Negotiate

  C->[underlying authentication library, hereafter called UAL] :
         "Can you authenticate to example.com?"

  [UAL]->C: "Sure thing. Here's a token to get started : [token1]"

  C->S : GET something
         Authorization: Negotiate [token1]

  S->C : HTTP/1.1 401 Need moar authentication
         WWW-Authenticate: Negotiate [token2]

  C->[UAL]: "example.com gave us [token2]. What should we do now?"

  [UAL]->C: "LOL. Who knows? Look a squirrel!"

  C: ...

  C: Shows ERR_INVALID_AUTH_CREDENTIALS to the user.

This should be considered a permanent error if there is actually no
other way to proceed. However, if there are other authentication schemes
to try, or if the initial authentication attempt was made using ambient
credentials and the scheme supports explicit credentials, then those
should be attempted next.

This CL changes the response of the network stack at the final step to
restart the network transaction by sending a request with no
Authorization header. This signals to the server that the client is
restarting the authentication handshake. It can then start over at which
point the client can attempt to use a different identity or a different
authentication scheme to proceed.

R=mmenke
BUG= 648366 

Review-Url: https://codereview.chromium.org/2382293004
Cr-Commit-Position: refs/heads/master@{#424563}
(cherry picked from commit e2257db89c38e2846d27a6de41a1ed4804ee5cab)

Review URL: https://codereview.chromium.org/2432873003 .

Cr-Commit-Position: refs/branch-heads/2840@{#758}
Cr-Branched-From: 1ae106dbab4bddd85132d5b75c670794311f4c57-refs/heads/master@{#414607}

[modify] https://crrev.com/4a2c7f5c92f114f0fbab7d8a5afe611b243fa286/net/http/http_auth_controller.cc
[modify] https://crrev.com/4a2c7f5c92f114f0fbab7d8a5afe611b243fa286/net/http/http_auth_controller.h
[modify] https://crrev.com/4a2c7f5c92f114f0fbab7d8a5afe611b243fa286/net/http/http_auth_controller_unittest.cc
[modify] https://crrev.com/4a2c7f5c92f114f0fbab7d8a5afe611b243fa286/net/http/http_network_transaction_unittest.cc

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

commit c0f81dce2f86e7dd4f87d68a1fc8501e29db2aad
Author: Asanka Herath <asanka@chromium.org>
Date: Thu Oct 20 02:08:26 2016

[M54] Fix build.

TBR=asanka@chromium.org
BUG= 648366 

Review URL: https://codereview.chromium.org/2438673002 .

Cr-Commit-Position: refs/branch-heads/2840@{#764}
Cr-Branched-From: 1ae106dbab4bddd85132d5b75c670794311f4c57-refs/heads/master@{#414607}

[modify] https://crrev.com/c0f81dce2f86e7dd4f87d68a1fc8501e29db2aad/net/http/http_network_transaction_unittest.cc

Is this issue is fixed? If yes, Could any one let us know is there manual repro steps available to verify this issue from Chrome-TE end.

Thanks!

Hi

I don't know if this can help you, but I'm getting "ERR_INVALID_HANDLE" and NO MORE "ERR_INVALID_AUTH_CREDENTIALS" also with Chrome version 54.0.2840.71 m (64-bit).

As you can see in comment #37 and #40 I had version 53.0.2785.143 m - 64-bit, and previously I was receiving ERR_INVALID_AUTH_CREDENTIALS.

Issue is still not resolved. Instead of ERR_INVALID_AUTH_CREDENTIALS, ERR_INVALID_HANDLE failure is indicated now in Version 54.0.2840.71 m (64-bit) :-\

royans: I'm removing the RB-Stable since this isn't a regression in Chrome and we don't have a verified fix yet. Once we have a verified fix we'll merge to stable but this issue shouldn't block interim stable releases. Please add the RB label if you disagree.

SG. Its a regression from customer view point, but I agree it doesn't meet the spirit of RBL. I agree with the recommendation of keeping the priority up, working on confirming a fix and pushing it to stable as you suggested.

I assume the bottomline is that until this bug is fixed, we expect some/all of win 10 units with latest patch set to fail NTLM handshake to proxies.

Is there a merge needed for M55?

#79: Not necessary at the moment.

Ok, sounds good. Thank you.

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

commit a3156ef390f3d8b4be451efd91ff4ce4897c8ef6
Author: Asanka Herath <asanka@chromium.org>
Date: Wed Oct 19 18:02:04 2016

[Merge-M54] [net] clang-format HttpNetworkTransactionTest.GenerateAuthToken test.

This is a pretty big test with a lot of test cases. clang-format pretty
much reformats the entire test beyond recognition. Subsequent patches
that may touch this test will be unreviewable if they also include the
formatting changes. Uploading the formatting changes separately.

BUG= 648366 

Review-Url: https://codereview.chromium.org/2385883002
Cr-Commit-Position: refs/heads/master@{#422429}
(cherry picked from commit c930761972fa8611069d0e55e3f45dd0c56c2d54)

Review URL: https://codereview.chromium.org/2431193004 .

Cr-Commit-Position: refs/branch-heads/2840@{#757}
Cr-Branched-From: 1ae106dbab4bddd85132d5b75c670794311f4c57-refs/heads/master@{#414607}

[modify] https://crrev.com/a3156ef390f3d8b4be451efd91ff4ce4897c8ef6/net/http/http_network_transaction_unittest.cc

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

commit 4a2c7f5c92f114f0fbab7d8a5afe611b243fa286
Author: Asanka Herath <asanka@chromium.org>
Date: Wed Oct 19 18:08:23 2016

[Merge-54][net/auth] Don't abort network transaction over non-permanent auth errors.

A multi-round authentication handshake may break partway through with an
error that indicates that the credentials used were invalid. With GSSAPI
we've seen this come up when the underlying library attempted to
authenticate against an endpoint even though no valid credentials were
available to finish the handshake. On Windows, this is now possible
since KB3189866.

Due to the fact that the underlying libraries attempt to start the
authentication handshake, the HttpNetworkTransaction proceeds past the
point where the HttpAuthController accepts the challenge and picks an
identity to use for the handshake. However, when the time comes to
generate a token, which happens just prior to sending the next HTTP
request, the HttpAuthController fails the operation with an
ERR_INVALID_AUTH_CREDENTIALS error. The state machine can't proceed past
this error and the user ends up looking at an error page.

e.g.:

  C->S : GET something

  S->C : HTTP/1.1 401 You shall not pass
         WWW-Authenticate: Negotiate

  C->[underlying authentication library, hereafter called UAL] :
         "Can you authenticate to example.com?"

  [UAL]->C: "Sure thing. Here's a token to get started : [token1]"

  C->S : GET something
         Authorization: Negotiate [token1]

  S->C : HTTP/1.1 401 Need moar authentication
         WWW-Authenticate: Negotiate [token2]

  C->[UAL]: "example.com gave us [token2]. What should we do now?"

  [UAL]->C: "LOL. Who knows? Look a squirrel!"

  C: ...

  C: Shows ERR_INVALID_AUTH_CREDENTIALS to the user.

This should be considered a permanent error if there is actually no
other way to proceed. However, if there are other authentication schemes
to try, or if the initial authentication attempt was made using ambient
credentials and the scheme supports explicit credentials, then those
should be attempted next.

This CL changes the response of the network stack at the final step to
restart the network transaction by sending a request with no
Authorization header. This signals to the server that the client is
restarting the authentication handshake. It can then start over at which
point the client can attempt to use a different identity or a different
authentication scheme to proceed.

R=mmenke
BUG= 648366 

Review-Url: https://codereview.chromium.org/2382293004
Cr-Commit-Position: refs/heads/master@{#424563}
(cherry picked from commit e2257db89c38e2846d27a6de41a1ed4804ee5cab)

Review URL: https://codereview.chromium.org/2432873003 .

Cr-Commit-Position: refs/branch-heads/2840@{#758}
Cr-Branched-From: 1ae106dbab4bddd85132d5b75c670794311f4c57-refs/heads/master@{#414607}

[modify] https://crrev.com/4a2c7f5c92f114f0fbab7d8a5afe611b243fa286/net/http/http_auth_controller.cc
[modify] https://crrev.com/4a2c7f5c92f114f0fbab7d8a5afe611b243fa286/net/http/http_auth_controller.h
[modify] https://crrev.com/4a2c7f5c92f114f0fbab7d8a5afe611b243fa286/net/http/http_auth_controller_unittest.cc
[modify] https://crrev.com/4a2c7f5c92f114f0fbab7d8a5afe611b243fa286/net/http/http_network_transaction_unittest.cc

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

commit c0f81dce2f86e7dd4f87d68a1fc8501e29db2aad
Author: Asanka Herath <asanka@chromium.org>
Date: Thu Oct 20 02:08:26 2016

[M54] Fix build.

TBR=asanka@chromium.org
BUG= 648366 

Review URL: https://codereview.chromium.org/2438673002 .

Cr-Commit-Position: refs/branch-heads/2840@{#764}
Cr-Branched-From: 1ae106dbab4bddd85132d5b75c670794311f4c57-refs/heads/master@{#414607}

[modify] https://crrev.com/c0f81dce2f86e7dd4f87d68a1fc8501e29db2aad/net/http/http_network_transaction_unittest.cc

Few of the cls are landed after M55 branch on October 6th. asanka@, could you please double check no merge is needed for M55? 

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

commit 08b7b4ad879c71ce3cfa82a83343c54a1e37a043
Author: Takeshi Yoshino <tyoshino@chromium.org>
Date: Mon Oct 31 08:00:25 2016

Reland the build fix patch I've reverted by mistake.

----

[M54] Fix build.

TBR=asanka@chromium.org
BUG= 648366 

Review URL: https://codereview.chromium.org/2438673002 .

Cr-Commit-Position: refs/branch-heads/2840@{#764}
Cr-Branched-From: 1ae106dbab4bddd85132d5b75c670794311f4c57-refs/heads/master@{#414607}
(cherry picked from commit c0f81dce2f86e7dd4f87d68a1fc8501e29db2aad)

Review URL: https://codereview.chromium.org/2461333002 .

Cr-Commit-Position: refs/branch-heads/2840@{#807}
Cr-Branched-From: 1ae106dbab4bddd85132d5b75c670794311f4c57-refs/heads/master@{#414607}

[modify] https://crrev.com/08b7b4ad879c71ce3cfa82a83343c54a1e37a043/net/http/http_network_transaction_unittest.cc

ERR_INVALID_AUTH_CREDENTIALS persists for this issue on the latest canary. This defect remains in the canary build. Is there any assistance I can provide or data I can gather to help diagnose it? 

I have a user with ERR_INVALID_HANDLE on Chrome v.54.0.2840.87, OS Windows 10.
In attachment is net-internals log if it can help.

Deleted: net-internals-log.json 1.3 MB

net-internals-log.json 1.3 MB View Download

Takeshi,

Are you seeing different results?

https://codereview.chromium.org/2489883007

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

commit 463ca4262fc277c5e724d02705ba1a61cbc4e849
Author: asanka <asanka@chromium.org>
Date: Wed Nov 16 02:34:31 2016

[net/auth] Discard current handler token generation fails.

Errors that occur during token generation should be considered fatal for
that instance of HttpAuthHandler. I.e. the handler should not be used to
process any additional authentication challenges and definitely should
not be used to generate any tokens.

Why? Because, any external state associated with an HttpAuthHandler may
not in a consistent or known state. While we would like to write auth
handlers that revert to a known safe state after a token generation
failure, that is not trivial when dealing with external token sources
with unpredictable behavior. Hence we are going to take the safer option
of tearing down the HttpAuthHandler following such a failure event.

In the case referred to in  https://crbug.com/648366 , we were leaving the
HttpAuthSspiWin in a state where it was expecting a new token, but the
credential handle it was in posession of could no longer be used to
generate a new token. This resulted in an ERR_INVALID_HANDLE error.
Oops.

R=mmenke@chromium.org
BUG= 648366 

Review-Url: https://codereview.chromium.org/2489883007
Cr-Commit-Position: refs/heads/master@{#432359}

[modify] https://crrev.com/463ca4262fc277c5e724d02705ba1a61cbc4e849/net/http/http_auth_controller.cc
[modify] https://crrev.com/463ca4262fc277c5e724d02705ba1a61cbc4e849/net/http/http_auth_controller.h
[modify] https://crrev.com/463ca4262fc277c5e724d02705ba1a61cbc4e849/net/http/http_auth_handler_mock.cc
[modify] https://crrev.com/463ca4262fc277c5e724d02705ba1a61cbc4e849/net/http/http_auth_handler_mock.h
[modify] https://crrev.com/463ca4262fc277c5e724d02705ba1a61cbc4e849/net/http/http_network_transaction_unittest.cc

 Issue 662001  has been merged into this issue.

 asanka@, could you please reply to comment #86. Thank you.

Adding "ReleaseBlock-Stable" label for M55 tracking. 

govind: Merge is needed for M55. There's one more CL incoming.

Please request a merge to M55 branch 2883 by appling "Merge-request-55" label once CLs are safe to merge. If merge happens latest before 4:00 PM PT Friday (11/18), then we can take them for next week last Beta release before stable promotion. Thank you.

A friendly reminder that M55 Stable is launch is coming soon! Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and get it merged into the release branch ASAP so it gets enough baking time in Beta (before Stable promotion). Thank you!

Also due to Thanksgiving holidays in US, please make sure fix is ready and merged to M55 latest by 5:00 PM PT Friday, 11/18/16 (sooner the better).

Hopefully the last required change is at https://codereview.chromium.org/2507253002

Hi

I'm now by my client where I have the problem (see comment #37 and #48).
I've just tried with Canary 56.0.2922.0 and all seems to work correctly.
Auth prompt popped up and after inserting my domain credentials I was able to navigate.

update:
the only (minor) issue is that the auth popup promps every time I close and open Chrome. It seems it doesn't save the credentials.

#100: Thanks for the confirmation. The pending CL should resolve the issue for folks who run into a related but separate case where they run into ERR_INVALID_HANDLE. But the change in #92 (available in Chrome Canary 56.0.2922.0) should address most of the cases in this thread.

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

commit 1d50f4974f89eebc449b0b8747b299267504e7ed
Author: asanka <asanka@chromium.org>
Date: Thu Nov 17 18:37:11 2016

[net/auth] Treat ERR_INVALID_HANDLE as a identity invalidating error.

BUG= 648366 

Review-Url: https://codereview.chromium.org/2507253002
Cr-Commit-Position: refs/heads/master@{#432922}

[modify] https://crrev.com/1d50f4974f89eebc449b0b8747b299267504e7ed/net/http/http_auth_controller.cc

I'll hold off on a merger request until we have verification that tomorrow Canary didn't burst into flames.

Thank you asanka@. 
Yeah, please request a merge to M55 once canary results look good. Thank you.

Leaving open until merge.

Could someone experiencing this issue try out today's Chrome Canary? The version should be 56.0.2924.0 or later.

#57 here. It was working for me since 56.0.2891.0 canary (64-bit) and is still working on 56.0.2924.0 canary (64-bit). So it did not break anything over night.

I was even asked for credentials this morning, as I sometimes am, so this seems to be working, too. (The server accepted "x" and "y" as username and password, though. I suspect this is due to the proxy server configuration: I can surf with IE without username/password and without having my computer registered in the Windows domain server.)

@paolo #101: Repeated requests for credentials MAY be related to the fact that multiple proxy servers are in use. In my case, those are xyzbluecoat2 through xyzbluecoat5 or so, and when a different browser session picks a different proxy server from the last one, the last password that Chrome stores by hostname may not be valid for the new proxy server. Just a guess.

Thanks!

Approving merge to M55 branch 2883 based on comment #108. Please merge ASAP. Thank you.

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

commit ae36ee015f06bbc8f925ef391b720828bb893407
Author: Asanka Herath <asanka@chromium.org>
Date: Fri Nov 18 18:44:08 2016

[Merge M55] [net/auth] Deal better with ERR_INVALID_AUTH_CREDENTIALS error.

This merges e2257db89c38e2846d27a6de41a1ed4804ee5cab,
463ca4262fc277c5e724d02705ba1a61cbc4e849, and
1d50f4974f89eebc449b0b8747b299267504e7ed to the M55 branch. Commit
messages follow in reverse order:

TBR=asanka@chromium.org

[net/auth] Treat ERR_INVALID_HANDLE as a identity invalidating error.

BUG= 648366 

Review-Url: https://codereview.chromium.org/2507253002
Cr-Commit-Position: refs/heads/master@{#432922}
(cherry picked from commit 1d50f4974f89eebc449b0b8747b299267504e7ed)

[net/auth] Discard current handler token generation fails.

Errors that occur during token generation should be considered fatal for
that instance of HttpAuthHandler. I.e. the handler should not be used to
process any additional authentication challenges and definitely should
not be used to generate any tokens.

Why? Because, any external state associated with an HttpAuthHandler may
not in a consistent or known state. While we would like to write auth
handlers that revert to a known safe state after a token generation
failure, that is not trivial when dealing with external token sources
with unpredictable behavior. Hence we are going to take the safer option
of tearing down the HttpAuthHandler following such a failure event.

In the case referred to in  https://crbug.com/648366 , we were leaving the
HttpAuthSspiWin in a state where it was expecting a new token, but the
credential handle it was in posession of could no longer be used to
generate a new token. This resulted in an ERR_INVALID_HANDLE error.
Oops.

R=mmenke@chromium.org
BUG= 648366 

Review-Url: https://codereview.chromium.org/2489883007
Cr-Commit-Position: refs/heads/master@{#432359}
(cherry picked from commit 463ca4262fc277c5e724d02705ba1a61cbc4e849)

[net/auth] Don't abort network transaction over non-permanent auth errors.

A multi-round authentication handshake may break partway through with an
error that indicates that the credentials used were invalid. With GSSAPI
we've seen this come up when the underlying library attempted to
authenticate against an endpoint even though no valid credentials were
available to finish the handshake. On Windows, this is now possible
since KB3189866.

Due to the fact that the underlying libraries attempt to start the
authentication handshake, the HttpNetworkTransaction proceeds past the
point where the HttpAuthController accepts the challenge and picks an
identity to use for the handshake. However, when the time comes to
generate a token, which happens just prior to sending the next HTTP
request, the HttpAuthController fails the operation with an
ERR_INVALID_AUTH_CREDENTIALS error. The state machine can't proceed past
this error and the user ends up looking at an error page.

e.g.:

  C->S : GET something

  S->C : HTTP/1.1 401 You shall not pass
         WWW-Authenticate: Negotiate

  C->[underlying authentication library, hereafter called UAL] :
         "Can you authenticate to example.com?"

  [UAL]->C: "Sure thing. Here's a token to get started : [token1]"

  C->S : GET something
         Authorization: Negotiate [token1]

  S->C : HTTP/1.1 401 Need moar authentication
         WWW-Authenticate: Negotiate [token2]

  C->[UAL]: "example.com gave us [token2]. What should we do now?"

  [UAL]->C: "LOL. Who knows? Look a squirrel!"

  C: ...

  C: Shows ERR_INVALID_AUTH_CREDENTIALS to the user.

This should be considered a permanent error if there is actually no
other way to proceed. However, if there are other authentication schemes
to try, or if the initial authentication attempt was made using ambient
credentials and the scheme supports explicit credentials, then those
should be attempted next.

This CL changes the response of the network stack at the final step to
restart the network transaction by sending a request with no
Authorization header. This signals to the server that the client is
restarting the authentication handshake. It can then start over at which
point the client can attempt to use a different identity or a different
authentication scheme to proceed.

R=mmenke
BUG= 648366 

Review-Url: https://codereview.chromium.org/2382293004
Cr-Commit-Position: refs/heads/master@{#424563}
(cherry picked from commit e2257db89c38e2846d27a6de41a1ed4804ee5cab)

Review URL: https://codereview.chromium.org/2518633002 .

Cr-Commit-Position: refs/branch-heads/2883@{#612}
Cr-Branched-From: 614d31daee2f61b0180df403a8ad43f20b9f6dd7-refs/heads/master@{#423768}

[modify] https://crrev.com/ae36ee015f06bbc8f925ef391b720828bb893407/net/http/http_auth_controller.cc
[modify] https://crrev.com/ae36ee015f06bbc8f925ef391b720828bb893407/net/http/http_auth_controller.h
[modify] https://crrev.com/ae36ee015f06bbc8f925ef391b720828bb893407/net/http/http_auth_controller_unittest.cc
[modify] https://crrev.com/ae36ee015f06bbc8f925ef391b720828bb893407/net/http/http_auth_handler_mock.cc
[modify] https://crrev.com/ae36ee015f06bbc8f925ef391b720828bb893407/net/http/http_auth_handler_mock.h
[modify] https://crrev.com/ae36ee015f06bbc8f925ef391b720828bb893407/net/http/http_network_transaction_unittest.cc

The code changes are small and there are plenty of tests. Let's see if it sticks.

@mr.ber #108: I tried five minutes ago (Canary 57.0.2926.0 x64). This time after inserting my credentials Canary asked if I wanted to save them. When I tried before (#100 and #101) I was not asked. Closing all canary sessions and opening the browser again now works (credentials saved)

Unable to reproduce this issue on Windows 10 Version 1607 using chrome reported version 54.0.2840.27 Beta by following steps mentioned in the original comment. Due to this we are not able to verify it on chrome latest Beta 55.0.2883.59 to confirm the fix.

 Issue 649664  has been merged into this issue.

Verified that build 55.0.2883.59 doesn't regress ambient authentication via NTLM and Negotiate. It also fails over to explicit credentials when ambient authentication fails.

Checking for an update.  When will the fix be pushed to stable chrome?

By https://www.chromium.org/developers/calendar, my guess would be Dec 6th, 2016.

I can verify that I no longer have the issue in Stable Chrome now that I have updated.