Chrome Kerberos Error Through Proxies
Reported by
signi...@gmail.com,
Aug 30 2016
|
|||
Issue description
Chrome Version : 52.0.2743.82 m
URLs (if applicable) : n/a
Other browsers tested: Version 51, 52, and 52 minor update
Add OK or FAIL, along with the version, after other browsers where you
have tested this issue:
Firefox: OK
IE: OK
What steps will reproduce the problem?
We seem to have found that the Chrome browser will not perform Kerberos authentication to both a proxy server and web server (through the proxy) at the same time. Chrome terminates the TCP session when this occurs. This is unexpected behavior, as both Internet Explorer and Firefox perform this without issue. The conditions required for this are that Chrome is configured to use an explicit proxy server (Proxy XYZ). Both the Proxy XYZ and the internal web server being called require Kerberos authentication. The following occurs. Chrome makes a request to the proxy server. The proxy server responds with a HTTP 407 proxy authorization required message. The Proxy-Authorization: header is set to negotiate to inform the client to use Kerberos and the proxy-connection header is set to close. The client closes the TCP session properly. The client opens a new TCP session and makes the same request again, this time including the proxy-authentication header with negotiate and the Kerberos ticket it obtained for the proxy server. The proxy server allows the request and makes the server side request to the internal web server. The web server replies back to the proxy with a HTTP 401 unauthorized message. The connection header is set to keep-alive that session and the www-authenticate header is set to negotiate to indicate Kerberos. The proxy returns that HTTP 401 back to the client. In that message both the proxy-connection and connection headers are set to keep-alive, and the www-authenticate header is still set to negotiate. At this point, Chrome terminates the TCP session. It starts a new TCP session, ignoring the keep-alive and the authentication headers. The whole process starts again exactly as before. This occurred twice before the page cannot be displayed messages was given to the user. In both Firefox and IE, after the web server’s HTTP 401 is sent back to the client from the proxy, the browser does not close the connection. The client makes the same request again, but this time including the Authorization header containing the Kerberos ticket for the web server. The proxy makes the request to the web server passing through that authorization header and Kerberos ticket from the client. The request is allowed, and authentication is complete for the sessions client to proxy, and proxy to server. Chrome is the only browser we have found that cannot perform Kerberos authentication to both the proxy and web server.
What is the expected result?
Chrome wont establish a new session and Kerberos would work as expected
What happens instead?
Chrome establishes a new session causing Kerberos authentication to behave improperly.
Please provide any additional information below. Attach a screenshot if
possible.
,
Aug 31 2016
,
Sep 1 2017
Issue has not been modified or commented on in the last 365 days, please re-open or file a new bug if this is still an issue. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot |
|||
►
Sign in to add a comment |
|||
Comment 1 by kavvaru@chromium.org
, Aug 31 2016Labels: TE-NeedsTriageHelp