Chrome warns me my connection is not secure when authenticating in SEDE with a Google account

Question

When I go to the login page of the Stack Exchange Data Explorer here and click the Log in using Google button, I'm not getting logged in but instead greeted with a Chrome message protecting my privacy:

The information you’re about to submit is not secure Because the site is using a connection that’s not completely secure, your information will be visible to others.

I'm pretty sure this worked yesterday without showing me that warning, so either Chrome got stricter overnight or a configuration change happened in SEDE as the revision is still at 2020.8.27.79 (when will my pull requests be deployed?).

When I inspect network traffic in the developer console I see:

• POST Request URL: https://data.stackexchange.com/user/authenticate
  • response: 302 with a location header: https://accounts.google.com/o/oauth2/auth?client_id=[blah]&scope=openid+email&redirect_uri=http%3a%2f%2fdata.stackexchange.com%2f[more blah]&response_type=code

And then the next call gets blocked, when the 302 is returned (careful readers saw this one coming):

• GET Request URL: https://accounts.google.com/o/oauth2/auth?client_id=[blah]&scope=openid+email&redirect_uri=http%3a%2f%2fdata.stackexchange.com%2f[more blah]&response_type=code
  • Response 302: Location: http://data.stackexchange.com/user/oauth/google?state=[blah]&code=[more blag]&scope=email+openid+https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fuserinfo.email&authuser=0&prompt=none

That last location header uses the HTTP protocol instead of the HTTPS protocol.

Can this be changed so that the POST route in /user/authenticate does use a secure protocol instead of plain HTTP?

I somehow expect this line in the AccountController.cs to be returning something different now:

private string BaseUrl => Current.Request.Url.Scheme + "://" + Current.Request.Url.Host;

because that BaseUrl gets added as the redirect_uri here

If an upstream proxy took over the SSL offloading it could well be that Current.Request.Url.Scheme no longer returns the HTTPS protocol I started with. But maybe other causes make that the scheme isn't what it used to be.

I seem to be the only one that can reproduce this in Chrome and even if this is only local to my machine, it still seems good advice to pre-emptively fix potential security risks instead of waiting for things to get abused.

If I accept the risk and proceed then I'm successfully logged in.

Answer 1

A fix for this has been deployed - thanks for the report and eyes on the PR as well!

Notes: yep, as you suspected, we terminate TLS at the load balancer and the built-in ASP net bits weren't reading the headers correctly behind that. In .NET Core this is solved, but Stack Exchange Data Explorer isn't on that yet and we don't have any time allocated to perform that work at this point in time.

Answer 2

Reproduced by me.

First when I registered using Google everything went fine.

I then logged out, and when logging in using the just registered Google account was greeted by the following message (in Dutch):

De gegevens die je wilt sturen, zijn niet beveiligd Omdat de site een verbinding gebruikt die niet volledig is beveiligd, zijn je gegevens zichtbaar voor anderen.

Which is the same message as Rene posted in the Question.

Using Chrome on Android.

Answer 3

Reproduced by me as well. Not only is the Google login being stroppy, clicking the "Login using Stack Overflow" button also throws this error:

Logged in or out of my Google account.