I was able to verify that this does not happen on a windows 8 machine running 51.0.2704.47.

Thanks for the report. The security bug template is intended for vulnerabilities, but no harm done. Removing view restrictions so that hopefully the right person can take a look.

Does the site use https ?

Also, could I get a net-internals log as described here? https://sites.google.com/a/chromium.org/dev/for-testers/providing-network-details

(The suspicion being that there's a MITM proxy and the resulting channel bindings are incorrect).

site is https with a Geotrust signed cert, no warnings/mucky trust arrangements.   attached is the net-internals log.

I replaced the actual site name with sso.example.com and the actual ip address of the site with 192.168.135.100 and the client mac's ip with 172.31.55.5, ports, protocols, etc all left the same, and all three replaced with %s,search,replace, in vim).  Please let me know if this causes problems.

A bit more detail of the exact arrangement I'm testing in -- between me and the internet there is a firewall (no proxies) and the internet to the web server, routers and no proxies.  The destination site in this example is running apache 2.2 (tho I've reproduced with a 2.4 destination site).  I've reproduced it from three different locations and two different server sides.  There's been chrome restarts and reboots since I first noticed it.

pleaes let me know if I can provide any other info.

thanks,
-Todd

Deleted: net-internals-log.json 493 KB

net-internals-log.json 493 KB View Download

fyi, this remains a problem in 51.0.2704.54 .

Yup. There were no pertinent changes in that build. To confirm, the same configuration works fine on M50, correct?

Would it be possible to capture a net-internals log without stripping private information? Of course you don't want to attach that log to this bug report, but you can email it directly to me. If not, I'll push a change to a Canary that you can try out.

It worked in 50 on the beta channel, but I also had some trouble in the first few releases of 50 that eventually fixed themselves on the second or third update that I ran.  I don't know the exact versions that I was running before, unfortunately.

I followed up privately with more detail on changing back what I changed in the attachment.

thanks again for your help,
-Todd

and to be clear, it was the same config.  It worked with 50, then I updated to 51 in the beta channel via automated updates, then it stopped working.

It is possible that I was already on 51 when the update happened that broke it and it actually broke in an update to 51, but I know for sure that it worked in versions of 50 because I had some other issues with some internal web sites at the same time that not issues with chromium, so I paid attention to the version a bit more closely than I may otherwise.

Sorry about the confusion. I was actually referring to clearing the "Strip private information (cookies and credentials)." checkbox in net-internals. Usually you want to leave it as is, but in this case we are trying to debug an issue with the credentials handshake.

The notable change in M51 is that Chrome now sends channel bindings by default. I can see from your net-internals log that the bindings were successfully generated which also means that Chrome communicate the bindings to the underlying security library. On a Mac, this would be Heimdal with Apple's modifications.

mod_auth_kerb doesn't support channel bindings. So in it always calls gss_accept_sec_context() with GSS_C_NO_CHANNEL_BINDINGS. Assuming you are running either MIT Kerberos or Heimdal on the server, this should result in the server ignoring the bindings sent by Chrome. Hence a failure attributed to channel bindings is unexpected.

Do you have any server side logs that show the error returned by the library? The relevent log entry should look like "gss_accept_sec_context() failed: <reason>".

I will provide the private information, well, privately.  Server error message is:

[Mon May 23 17:25:54.375397 2016] [auth_kerb:error] [pid 4263:tid 140373288515328] [client 172.31.55.5:64141] gss_accept_sec_context() failed: Unspecified GSS failure.  Minor code may provide more information (, Invalid field length in token)

server is running MIT (ubunutu 14.04, so 1.12).  mod_auth_kerb 5.4.

#15. Thanks. Yeah, that's disconcerting. I'll try to reproduce this.

Huh. Just to check, can you try removing the site in question from the AuthDelegateWhitelist but leave it in AuthServerWhitelist?

I think you meant AuthNegotiateDelegateWhitelist, since AuthDelegateWhitelist is not set. It still does not work -- I:
defaults delete com.google.Chrome AuthNegotiateDelegateWhitelist

thus leaving:

{
    AuthServerWhitelist = "sso.example.com";
    KeychainReauthorizeAtUpdateMay2012 = 3;
    KeychainReauthorizeAtUpdateMay2012Success = 1;
    LastRunAppBundlePath = "/Applications/Google Chrome.app";
    NSNavLastRootDirectory = "~/Downloads";
    NSNavLastUserSetHideExtensionButtonState = 0;
    NSNavPanelExpandedSizeForOpenMode = "{704, 440}";
    NSNavPanelExpandedSizeForSaveMode = "{712, 1332}";
    NSNavPanelExpandedStateForSaveMode = 0;
    NSTreatUnknownArgumentsAsOpen = NO;
    NSWindowHostsLayersInWindowServer = YES;
    PMPrintingExpandedStateForPrint2 = 1;
}

and it reuurned a 401.  Do you want the net-internals capture from this as well?

thanks,
-Todd

Nope. Thanks for checking!

This is in fact triggered by the channel bindings change. :-/

The issue affects configurations using stock MIT Kerberos on their servers and using Mac OS X clients. The issue does not manifest itself when using Heimdal on the server nor does it manifest itself when using stock MIT or Heimdal on the client. The issue also doesn't affect Windows servers or clients.

Starting with M51 GSSAPI/SPNEGO/Kerberos 5 authentication between Chrome clients on Posix platforms and compliant servers will exchange tls-server-endpoint channel bindings if the underlying channel supports it. Chrome itself doesn't implement the token encoding, but invokes the GSSAPI library on the host to do the work.

Kerberos 5 GSSAPI mechanism communicates these channel bindings via the checksum field in the KRB_AP_REQUEST's authenticator as described in RFC 4121 section 4.1.1. The "checksum" field looks like this (from RFC 4121):

     The authenticator checksum field SHALL have the following format:

       Octet        Name      Description
      -----------------------------------------------------------------
       0..3         Lgth    Number of octets in Bnd field;  Represented
                            in little-endian order;  Currently contains
                            hex value 10 00 00 00 (16).
       4..19        Bnd     Channel binding information, as described in
                            section 4.1.1.2.
       20..23       Flags   Four-octet context-establishment flags in
                            little-endian order as described in section
                            4.1.1.1.
       24..25       DlgOpt  The delegation option identifier (=1) in
                            little-endian order [optional].  This field
                            and the next two fields are present if and
                            only if GSS_C_DELEG_FLAG is set as described
                            in section 4.1.1.1.
       26..27       Dlgth   The length of the Deleg field in
                            little-endian order [optional].
       28..(n-1)    Deleg   A KRB_CRED message (n = Dlgth + 28)
                            [optional].
       n..last      Exts    Extensions [optional].

Of these, the encoding for the optional Extensions field is not described in RFC 4121.

Mac OS X 10.7+ ships with a modified Heimdal. The modified source code can be found at http://opensource.apple.com/. These modifications include a provision to encode a KRB5_KU_GSSAPI_EXTS extension into the Extensions field if channel bindings are provided to  gss_init_sec_context(). Stock Heimdal does not have this behavior.

The Heimdal encodes the Extensions field using the following format:

      Octet     Description
      -----------------------------------------------------------------
      0..1      Type ID for the extension in little-endian order (16 bits).
                Type ID for KRB5_KU_GSSAPI_EXTS is 43.

      2..3      Length of extension data in little-endian order (16 bits).

      4..last   Extension data.

(Note use of store_ext() in _gsskrb5_create_8003_checksum() in http://opensource.apple.com/source/Heimdal/Heimdal-453.20.2/lib/gssapi/krb5/8003.c . store_ext() encodes an extension according to the format described above and uses 16 bit types and lengths encoded in little-endian order.)

On the server side, during gss_accept_sec_context(), MIT Kerberos also looks at the checksum field. If no channel bindings are provided to gss_accept_sec_context(), the bindings described in the checksum are ignored. However, MIT Kerberos still attempts to parse the Extensions field. The format expected by MIT Kerberos is as follows.

      Octet     Description
      -----------------------------------------------------------------
      0..3      Type ID for the extension in little-endian order (32 bits).

      4..7      Length of extension data in little-endian order (32 bits).

      8..last   Extension data.

(Note use of TREAD_INT() to read type and length of extension in https://github.com/krb5/krb5/blob/89683d1f135765e91041f3a239af865b11aaf86b/src/lib/gssapi/krb5/accept_sec_context.c#L831 . TREAD_INT reads a 32-bit integer in little-endian order).

As you might imagine, when the KRB5_KU_GSSAPI_EXTS extension is present and encoded by the Heimdal client, the MIT Kerberos code goes off the rails while decoding the Extensions field. It parses the extension data as the Length of the extension field and returns a KG_BAD_LENGTH error when it notices that the length exceeds the extents of the checksum field.

The KG_BAD_LENGTH code is logged via mod_auth_kerb as the string "gss_accept_sec_context() failed: Unspecified GSS failure.  Minor code may provide more information (, Invalid field length in token)"


rsleevi, govind, dskaram, cbentzel: I'll follow up with MIT about what the correct encoding is. For M51, I'm going to disable channel bindings on Posix platforms. It was only critical for Windows clients, and at this point it's apparent that there are interop issues to be ironed out before we can roll it out on Posix.

We're cutting M51 Stable RC today and this bug has been marked as M51 Stable blocker. Does this require merge to M51 branch?

Unfortunately, without the patch (which I'm testing right now), folks using Negotiate authentication on Mac OS X clients against MIT Kerberos servers over HTTPS connections will fail to authenticate. So "yes". I'll make the patch as safe as possible. The resulting behavior will be equivalent to pre M51.

Thank you asanka@. How long will take the patch to be ready and merge?

+ sshruthi@ [M51 Desktop TPM]

As we're cutting RC today, the change will not have time to land/baked/verified in Canary? Shruthi will that be ok? 

@govind: The patch itself should be ready in a couple of hours.

@todd.kover: Would you be able to try out a test build? I can send you instructions over email. It would be very helpful for us to get verification for the fix.

definitely able and happy to test.

Excellent. I'll have a build ready shortly.

Regarding c#24, we can make a call once asanka@ has a patch. Please note this build is planned for Stable channel, so the bar is very high to justify skipping bake time. 

With the test build, I had to start with:

open ./Chromium.app/ --args --user-data-dir=/tmp/test_profile --auth-server-whitelist=sso.example.com

but it worked.  Without the --auth-server-whitelist, it didn't even try negotiate auth. (no service tickets in the ticket cache).  

#29: Thanks for the confirmation!

The --auth-server-whitelist flag is required. Chrome only attempts Negotiate with whitelisted servers.

#30: Will this respect the values in OS X defaults? e.g `defaults read com.google.chrome AuthServerWhitelist`.

#31. Yes, there's no change in behavior there. #31 was specifically about the test build that I sent to @todd.

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

commit ccb5d4fc7a7e1045bd11fa7710879d4a6df850ed
Author: asanka <asanka@chromium.org>
Date: Tue May 24 19:30:44 2016

[net/auth] Disable use of channel bindings on Posix.

We ran into interoperability issues on Mac OS X clients and MIT Kerberos
servers. (See bug for details). Out of an abundance of caution, we are
reverting to pre M51 behavior for Posix platforms.

R=rsleevi@chromium.org
BUG= 611728 

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

[modify] https://crrev.com/ccb5d4fc7a7e1045bd11fa7710879d4a6df850ed/net/http/http_auth_gssapi_posix.cc

I wrote the CL in #33 to be as minimal as possible. It's effect is as follows:

Windows:
  No behavior change. The change doesn't affect the Windows build at all.

Mac/Linux:
  Folks on the stable channel will see no change. We didn't support channel bindings with GSSAPI on M50, and we will continue to not support it in M51 if this change is merged to branch.

  Folks on pre-release channels will go back to M50 behavior with respect to HTTP authentication. The only change is in Chrome's support of channel bindings. This isn't expected to cause a regression on Posix platforms. Users affected by this bug will see their deployments return to their prior level of functionality.

ChromeOS/Android/iOS:
  No effect. GSSAPI wasn't supported on these platforms.

Based on conversation with asanka@ and c#34, that this is a super safe change, brings M51 back to where things were pre-51 as well as on M50, the current stable channel.

Merge approved for M51 (branch 2704)

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

commit e2fbb0012fdd47482365096f659d947b07fe4b2b
Author: Asanka Herath <asanka@chromium.org>
Date: Tue May 24 20:54:27 2016

[Merge M51][net/auth] Disable use of channel bindings on Posix.

We ran into interoperability issues on Mac OS X clients and MIT Kerberos
servers. (See bug for details). Out of an abundance of caution, we are
reverting to pre M51 behavior for Posix platforms.

R=rsleevi@chromium.org
BUG= 611728 

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

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

Cr-Commit-Position: refs/branch-heads/2704@{#655}
Cr-Branched-From: 6e53600def8f60d8c632fadc70d7c1939ccea347-refs/heads/master@{#386251}

[modify] https://crrev.com/e2fbb0012fdd47482365096f659d947b07fe4b2b/net/http/http_auth_gssapi_posix.cc

Thanks everyone! And now we wait.

Requesting merge to M-52.

Due to the imminent stable cut, I merged the change to M-51 first. It's since been rolled out and nothing terrible happened on ToT nor stable.

Your change meets the bar and is auto-approved for M52 (branch: 2743)

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

commit 3110bd3f5d4c518429c931113f03601a26bd465b
Author: Asanka Herath <asanka@chromium.org>
Date: Thu May 26 17:56:54 2016

[Merge M52][net/auth] Disable use of channel bindings on Posix.

We ran into interoperability issues on Mac OS X clients and MIT Kerberos
servers. (See bug for details). Out of an abundance of caution, we are
reverting to pre M51 behavior for Posix platforms.

R=rsleevi@chromium.org
BUG= 611728 

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

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

Cr-Commit-Position: refs/branch-heads/2743@{#80}
Cr-Branched-From: 2b3ae3b8090361f8af5a611712fc1a5ab2de53cb-refs/heads/master@{#394939}

[modify] https://crrev.com/3110bd3f5d4c518429c931113f03601a26bd465b/net/http/http_auth_gssapi_posix.cc