Issue metadata
Sign in to add a comment
|
HTTP/2 Should fallback to HTTP/1.1 when trying to authenticate using NTLM.
Reported by
nickst...@gmail.com,
Apr 20 2017
|
||||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.81 Safari/537.36 Example URL: Steps to reproduce the problem: 1. Have an Angular2 website and a ASP.NET WebAPI endpoint both hosted on IIS10 on Windows Server 2016. 2. The ASP.NET WebAPI should be setup to authenticate using NTLM. Both should be served of SSL/TLS. 3. Install Chrome 4. Launch Chrome 5. Browse to your Angular2 site that's hosted over SSL/TLS. 6. The Angular2 website should make an GET ajax request to the ASP.NET WebAPI endpoint. What is the expected behavior? Should fallback to HTTP/1.1 when trying to authenticate using NTLM. What went wrong? Your GET Ajax request will fail because it is trying to use HTTP/2 to authenticate with NTLM. Did this work before? N/A Chrome version: 58.0.3029.81 Channel: stable OS Version: 6.3 Flash Version: Shockwave Flash 25.0 r0 This is because NTLM Authentication is not Compatible with HTTP/2. https://www.iis.net/learn/get-started/whats-new-in-iis-10/http2-on-iis Chromes implementation of NTLM request does not fallback to HTTP/1.1 until a second request is made. Firefox 52 has the same issue as Chrome. A bug has been filed and a fix has been made for Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1346392 Microsoft says the browser should downgrade the connection to HTTP/1.1 when an NTLM Authentication request is made https://www.fxsitecompat.com/en-CA/docs/2017/ntlm-authentication-fails-in-certain-cases/
,
Apr 24 2017
If you look at the Firefox bug report they used Sharepoint on Windows Server 2016 with NTLM authentication. That might make it a little easier to reproduce because it is a commercial product.
,
Apr 25 2017
I can help test please let me know.
,
Apr 26 2017
The server can initiate a downgrade, but it makes sense for the UA to downgrade since it is the one making the decision to use a connection based authentication mechanism. The server currently can initiate a downgrade and that code path currently works. +bnc for FHI
,
Apr 26 2017
,
Apr 26 2017
Please record and upload a network log according to https://sites.google.com/a/chromium.org/dev/for-testers/providing-network-details. In particular, I am interested to see how exactly the request fails. RFC7540 recommends that the server sends an HTTP_1_1_REQUIRED error to the client, and I expect Chrome to handle it properly.
,
May 3 2017
Working on getting you a log. I can tell you the server does send HTTP_1_1_Required.
,
May 3 2017
Note that this is very likely a duplicate of issue 717329. I misspoke in #4 that the server downgrade path currently works.
,
May 15 2017
Thank you for uploading the log in comment #9. In that, I see the following: Preconnect opens two sockets: 775 and 776. 778 URL_REQUEST starts 782 HTTP_STREAM_JOB, which binds to 776 SOCKET, creates 783 HTTP2_SESSION, and sends request on stream 1. This fails with status code 401. Retry happens in 785 HTTP_STREAM_JOB, which binds to the same SOCKET, same HTTP2_SESSION, and sends the request with authorization headers on stream 3. This causes the server to send HTTP_1_1_REQUIRED error. The retry logic, still in the same URL_REQUEST, starts up 788 HTTP_STREAM_JOB, which binds to 775 SOCKET, another idle socket to the same host. Unfortunately, this is also HTTP/2. This should not happen: instead, a new socket should be opened, and no "h2" should be sent out in the ALPN extension of the TLS client hello. This is the exact same situation as the one described at https://crbug.com/717329#c21.
,
May 15 2017
Thank you #10 for the feedback. I am unable to see issue 717329. Is it currently being worked on, and does it have a timeline for completion?
,
May 15 2017
Issue 717329 has been merged into this issue.
,
May 15 2017
Re #11: It is in my queue. I do not think I'll be able to tackle this before M60 cuts, so I'm targeting M61. I merged issue 717329 into this one so that the progress can be tracked publicly.
,
Aug 23 2017
Do you have an idea when this will be fixed?
,
Aug 29 2017
,
Aug 31 2017
,
Sep 13 2017
Any chance for an ETA on this? We're having major problems due to this bug. Thanks, Ron |
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by ligim...@chromium.org
, Apr 20 2017Labels: -Pri-2 M-58 Pri-1
Owner: asanka@chromium.org
Status: Assigned (was: Unconfirmed)