az login broken on chrome with ERR_SSL_PROTOCOL_ERROR

[juliusl]

This is autogenerated. Please review and update as needed.

Describe the bug

When I try to do az login on my dev machine it will not succeed in Chrome. In edge I need to refresh the browser for the login process to finish. This was also broken 19 days ago so this time I tried and disabled all of my ad/tracker blocking extensions in chrome. However that didn't seem to help.

Command Name
az login

Errors:

To Reproduce:

Steps to reproduce the behavior. Note that argument values have been redacted, as they may contain sensitive information.

• Put any pre-requisite steps here...
• az login

Trying in Google chrome (doesn't work):

Url --

https://localhost:8400/?code=<redacted>&state=<redacted>&session_state=<redacted> <-- If you need redacted values please ask.

In Browser --

This site can’t provide a secure connection localhost sent an invalid response.
Try running Windows Network Diagnostics.
ERR_SSL_PROTOCOL_ERROR

Trying in edge by changing default browser to edge. (partially works):

D:\un\acr\DevServices-ContainerRegistry-Service\src\ibiza\KraterExtension>az login
Note, we have launched a browser for you to login. For old experience with device code, use "az login --use-device-code"
----------------------------------------

It was stuck on this for about a minute or two and then I decided to refresh the browser, then this happened below. It seemed to proceed to login from there.

Exception happened during processing of request from ('127.0.0.1', 49737)
Traceback (most recent call last):
  File "C:\Program Files (x86)\Microsoft SDKs\Azure\CLI2\lib\socketserver.py", line 317, in _handle_request_noblock
    self.process_request(request, client_address)
  File "C:\Program Files (x86)\Microsoft SDKs\Azure\CLI2\lib\socketserver.py", line 348, in process_request
    self.finish_request(request, client_address)
  File "C:\Program Files (x86)\Microsoft SDKs\Azure\CLI2\lib\socketserver.py", line 361, in finish_request
    self.RequestHandlerClass(request, client_address, self)
  File "C:\Program Files (x86)\Microsoft SDKs\Azure\CLI2\lib\socketserver.py", line 721, in __init__
    self.handle()
  File "C:\Program Files (x86)\Microsoft SDKs\Azure\CLI2\lib\http\server.py", line 418, in handle
    self.handle_one_request()
  File "C:\Program Files (x86)\Microsoft SDKs\Azure\CLI2\lib\http\server.py", line 386, in handle_one_request
    self.raw_requestline = self.rfile.readline(65537)
  File "C:\Program Files (x86)\Microsoft SDKs\Azure\CLI2\lib\socket.py", line 586, in readinto
    return self._sock.recv_into(b)
ConnectionResetError: [WinError 10054] An existing connection was forcibly closed by the remote host
----------------------------------------
You have logged in. Now let us find all the subscriptions to which you have access...

Expected Behavior

Login works.

Environment Summary

Windows-10-10.0.18362-SP0
Python 3.6.6
Shell: cmd.exe

azure-cli 2.0.71 *

Additional Context

[jiasli]

This is a typical browser setup issue (possibly enabled by some extensions) where the browser is forcing traffic through https://localhost:8400. CLI fails because localhost only works with HTTP.

To remove this HTTPS policy,

1. For Edge, go to edge://net-internals/#hsts; for Google Chrome, go to chrome://net-internals/#hsts
2. Under Delete domain security policies, fill in localhost and click Delete

More info: https://stackoverflow.com/a/28586593/2199657

[yugangw-msft]

On top of @jiasli's suggestion, you can use az login --use-device-code to get unblocked meanwhile.

[juliusl]

@jiasli

[jiasli]

Does deleting localhost from Delete domain security policies solve the issue?

[juliusl]

@jiasli Yup that seems to fix it. Closing now. Thanks!

[jiasli]

For Edge's hang issue, may be related to #10578.

[IanKemp]

I feel like this Chrome localhost issue should be called out on the documentation pages for az login and Connect-AzAccount.

[MaybeSacred]

Note that Chrome will "helpfully" map http to https in the URL, which needs to be undone for this to work

[IanKemp]

This is a typical browser setup issue (possibly enabled by some extensions) where Chrome is forcing traffic through https://localhost:8400. CLI fails because it only works with HTTP.

To remove this HTTPS policy,

1. Go to chrome://net-internals/#hsts
2. Under Delete domain security policies, fill in localhost and click Delete

More info: https://stackoverflow.com/a/28586593/2199657

This begs the questions, "Why does the CLI only work with HTTP?" and "What is Microsoft going to do to address this?".

[jiasli]

Note that Chrome will "helpfully" map http to https in the URL, which needs to be undone for this to work

I am using Chrome for development and daily usage. As far as I know, Chrome by itself doesn't do the redirection by default. Some extensions or policies might turn that on.

This begs the questions, "Why does the CLI only work with HTTP?" and "What is Microsoft going to do to address this?".

Because it is not possible to make HTTPS work on localhost without trusting a self-signed certificate. In other words, it is not possible to get a public HTTPS certificate for localhost. Redirecting http://localhost to https://localhost is simply a wrong behavior, as http://localhost is only used for local development and HTTPS should NOT be enforced.

Using http://localhost is the standard workflow of Auth Code flow:

redirect_uri: The redirect_uri of your app, where authentication responses can be sent and received by your app. It must exactly match one of the redirect_uris you registered in the portal, except it must be url encoded. For native & mobile apps, you should use one of the recommended values - https://login.microsoftonline.com/common/oauth2/nativeclient (for apps using embedded browsers) or http://localhost (for apps that use system browsers).

I feel like this Chrome localhost issue should be called out on the documentation pages for az login and Connect-AzAccount.

This is definitely a good suggestion and we will put that in the document. Thanks for the suggestion!

[welersonlisboa]

solve here - #26180

[jiasli]

@welersonlisboa, ERR_SSL_PROTOCOL_ERROR is not relevant to #26180.

[jiasli]

BTW, redirecting to localhost is a designed behavior and defined by the OAuth 2.0 authorization code flow.