I was able to reproduce. Load fails with ERR_CONNECTION_RESET. Looks like the server is dropping the connection during the TLS handshake. However, if I leave the page open it succeeds on an auto-retry.

Attached netlog shows error on first connect and success on retry.

Deleted: adfs-net-export2.json 366 KB

adfs-net-export2.json 366 KB View Download

From our internal network it never succeeds.  All the others browsers work first time, every time.   Not sure where to go from here.  Any advice? 

I uninstalled Chrome and installed Google Chrome Enterprise V66.164.84 and the site comes up first time, every time.  After it upgrades it no longer works.  Hope that helps.

By "first time, every time" do you restart between attempts? Otherwise you'll probably just re-use an existing connection. I tested a bit more and it seems sometimes just get lucky and it works on the first try. Othertimes I had to reload a few dozen times before it worked.

Also can you double check that version? V66.164.84 doesn't look like a chrome version number.

I tried with a number of older versions and see the same behavior so I'm unsure that it is due to any recent change in chrome.

Can you look at it from the server side and confirm the server is dropping the connections? If not, maybe it's some middlebox interfering with the connections.

As per comment #0 we have tested this issue on reported chrome version 67.0.3396.87 and latest chrome 69.0.3466.0 using Windows 10, With high DPI & Surface pro. Attaching screen-cast for reference.

Steps:
--------
1. Launched chrome
2. Navigated to given URL ""https://adfs.morganlewis.net/adfs/ls/idpinitiatedsignon.aspx""
We are able to see the login page.

Note: Uninstalled & Reinstalled chrome browser and also closed and reopened multiple times.

@Reporter: As we are unable to reproduce the issue from our end. Could you please review the attached screen-cast and confirm if anything being missed here.Can you verify this issue with fresh profile that is not having any extensions and apps or reset all the flags and please respond to comment #5.

Thanks! 

Deleted: 855155.mp4 4.1 MB

	855155.mp4 4.1 MB View Download

My apologies, the version that it works on is 51.0.2704.84 (64 bit).  

We are in the process of building a Windows 10 Enterprise system with a clean (from MS) build, not our custom tailored build. From there we will do a clean install of the latest Chrome and test it off our network to replicate your testing.  

Thanks for your hard work and quick responses on this.  I will post our test results later today.

Thanks, I hadn't tried versions that old. 

I did some bisecting, looks like things start failing after r401793, which removes DHE cipher support:
https://chromium.googlesource.com/chromium/src/+/b4c25b632a7078d2c3346a37b51034bb853b24b3

(Although after that CL the error is ERR_SSL_OBSOLETE_CIPHER, the error becomes ERR_CONNECTION_RESET after https://chromium.googlesource.com/chromium/src/+/6b4943bfc61acc877f92b183b849922edbe85e8d.)

As for why it is a flaky failure.. perhaps the site is load-balanced between multiple servers and some of them have different ciphersuite configurations? Or again, could be some middlebox doing something weird.

Yes, this is multiple servers load balanced.  I did isolate the request to a single server using a hosts. file but it still has the same problem but it could be the Cipher deprecation.   I'll look into that from the server side.

Thanks for the clue. 

Here is the list of Cyper's configured on the server:

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P384
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P384
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P384
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384_P384
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P384
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P384
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
TLS_DHE_DSS_WITH_AES_256_CBC_SHA
TLS_DHE_DSS_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_RC4_128_MD5
TLS_RSA_WITH_NULL_SHA256
TLS_RSA_WITH_NULL_SHA
SSL_CK_RC4_128_WITH_MD5
SSL_CK_DES_192_EDE3_CBC_WITH_MD5

Can you advise which ones are NOT compatible?   I will also run this past MS support.

Thanks.

It doesn't look like it's failing due to the cipher business. I think that's a red herring due to how that error is detected (which is necessarily a bit flaky). Rather it's resetting the connection quite late.

This looks rather like the old Microsoft AES-GCM bug, actually. One of their updates way way back had a bug that broke their AES-GCM ciphers. They fixed it within a month, but some servers did not take the update.

The advice I got from Microsoft way back was that you want to install KB3042058 (https://support.microsoft.com/en-us/kb/3042058) and its prerequisites. Note that KB3042058 describes important prerequisites that must be installed prior to installing KB3042058.

Did Comment #11 resolve your issue? We'll be looking to auto-close this issue without further follow-up.

[john.mcglinchey]:  Did comment #11 resolve the issue?  If we don't hear back from you, we'll have to just close this issue.

You can close this issue.  #11 was the resolution.

Thanks,

John


John F. McGlinchey
Manager of Desktop Engineering
Morgan, Lewis & Bockius LLP
1701 Market Street | Philadelphia, PA 19103-2921
Direct: +1 215.963.4639 | Main: +1 215.963.5000 | Fax: +1 215.963.5001
jmcglinchey@morganlewis.com<mailto:jmcglinchey@morganlewis.com> | www.morganlewis.com<http://www.morganlewis.com/>

From: mme… via monorail <monorail+v2.3079273537@chromium.org>
Sent: Wednesday, July 25, 2018 12:21 PM
To: McGlinchey, John F. <john.mcglinchey@morganlewis.com>
Subject:  Issue 855155  in chromium: Chrome will not display IDP web page for ADFS authentication

[EXTERNAL EMAIL]