Chrome warnt mich, dass meine Verbindung bei der Authentifizierung in SEDE mit einem Google-Konto nicht sicher ist

Dec 13 2020

Wenn ich auf die Anmeldeseite des Stapel Exchange Data Explorer gehen hier und klicken Sie auf das Anmelden mit Google - Taste, bin ich nicht angemeldet zu werden, sondern mit einer Chrome Nachricht Schutz meiner Privatsphäre begrüßt:

Die Informationen, die Sie übermitteln möchten, sind nicht sicher. Da die Site eine Verbindung verwendet, die nicht vollständig sicher ist, sind Ihre Informationen für andere sichtbar.

Ich bin mir ziemlich sicher, dass dies gestern funktioniert hat, ohne dass mir diese Warnung angezeigt wurde. Daher wurde Chrome über Nacht strenger oder es kam zu einer Konfigurationsänderung in SEDE, da die Revision noch am 2020.8.27.79 ist (wann werden meine Pull-Anforderungen bereitgestellt?).

Wenn ich den Netzwerkverkehr in der Entwicklerkonsole überprüfe, sehe ich:

  • POST-Anforderungs-URL: https://data.stackexchange.com/user/authenticate
    • Antwort: 302 mit einem Standortheader: 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

Und dann wird der nächste Anruf blockiert, wenn der 302 zurückgegeben wird (sorgfältige Leser haben diesen kommen sehen):

  • GET-Anforderungs-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
    • Antwort 302: Ort: 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

Dieser letzte Speicherort-Header verwendet das HTTP-Protokoll anstelle des HTTPS-Protokolls.

Kann dies geändert werden, sodass die POST-Route in / user / authenticate ein sicheres Protokoll anstelle von einfachem HTTP verwendet?

Ich erwarte irgendwie, dass diese Zeile in AccountController.cs jetzt etwas anderes zurückgibt:

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

weil diese BaseUrl als die hier hinzugefügt wirdredirect_uri

Wenn ein Upstream-Proxy das SSL-Offloading übernommen hat, kann es durchaus sein, dass Current.Request.Url.Schemedas von mir gestartete HTTPS-Protokoll nicht mehr zurückgegeben wird. Aber vielleicht führen andere Ursachen dazu, dass das Schema nicht mehr so ​​ist, wie es früher war.

Ich bin anscheinend der einzige, der dies in Chrome reproduzieren kann, und selbst wenn dies nur auf meinem Computer lokal ist, scheint es dennoch ein guter Rat zu sein, potenzielle Sicherheitsrisiken vorbeugend zu beheben, anstatt darauf zu warten, dass Dinge missbraucht werden.

Wenn ich das Risiko akzeptiere und fortfahre, bin ich erfolgreich angemeldet.

Antworten

8 NickCraver Dec 14 2020 at 04:44

Ein Fix dafür wurde bereitgestellt - danke für den Bericht und die PR!

Anmerkungen: Ja, wie Sie vermutet haben, beenden wir TLS am Load Balancer und die integrierten ASP-Netzbits haben die Header dahinter nicht richtig gelesen. In .NET Core ist dies behoben, aber der Stack Exchange Data Explorer ist noch nicht aktiviert, und wir haben zu diesem Zeitpunkt keine Zeit, um diese Arbeit auszuführen.

5 Luuklag Dec 13 2020 at 16:41

Von mir reproduziert.

Als ich mich bei Google registriert habe, ist alles gut gegangen.

Ich habe mich dann abgemeldet und beim Anmelden mit dem gerade registrierten Google-Konto wurde die folgende Meldung (auf Niederländisch) angezeigt:

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 andere.

Welches ist die gleiche Nachricht wie Rene in der Frage gepostet.

Verwenden von Chrome unter Android.

1 Ollie Dec 14 2020 at 03:46

Auch von mir reproduziert. Das Google-Login ist nicht nur unübersichtlich. Wenn Sie auf die Schaltfläche "Login mit Stapelüberlauf" klicken, wird auch dieser Fehler ausgegeben:

Angemeldet oder von meinem Google-Konto abgemeldet.