Description

When SSO is enabled, the public_baseurl is set to an https scheme endpoint, and the site is running
behind a reverse proxy that terminates ssl and forwards all traffic as http the SSO login redirect will
infinitely loop because the request is for an http endpoint but the public_baseurl is pointed at an
https endpoint. The root of the issue is the simple startswith bytes check inside the SSO redirect
that is meant to make sure that cookies are set on the right domain (#9436).

The public_baseurl mentions that it should be set to the same scheme as what is behind the reverse proxy
however that results in clients like element web being unable to resolve resources behind the reverse proxy
as they aren't always obeying 301 and 302 redirects for resources and exposing the http endpoint externally is
undesirable.

Workaround

The current work around used on my homeserver (matrix.nulloctet.com) is to point the reverse proxy at the https
backend for synapse and leave the public_baseurl as https://matrix.nulloctet.com/. This results in no loop because
the web request is on the same scheme as the public_baseurl. However I am not a fan of terminating an TLS connection only to remote proxy another TLS connection behind the scene. I also do not want to run synapse
completely public as that would be a regression in functionality and would be a special snowflake among the other
services I run.

Proposed Solution

The check of the request and the public_baseurl should completely ignore the scheme, as only the dns name
is required to match for cookies to be correctly set.

Steps to reproduce

• Set public_baseurl to use https scheme
• Setup; reverse proxy that forwards all https traffic to the http endpoint of synapse
• Enable an SSO provider
• Attempt to login with that provider

Version information

• Homeserver: matrix.nulloctet.com

If not matrix.org:

Versions Tested:

• Version: 1.38.1

• Version: 1.37.1

• Version: 1.35.0

• Install method: Docker-Compose

• Platform: Ubuntu Linux 20.04 HWE with Docker CE