Skip to content

Only HTTPS redirect for a specific host (the one with a valid cert) #21506

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
dustinmoris opened this issue May 5, 2020 · 4 comments
Open
Labels
affected-few This issue impacts only small number of customers area-middleware Includes: URL rewrite, redirect, response cache/compression, session, and other general middlewares enhancement This issue represents an ask for new feature or an enhancement to an existing one Needs: Design This issue requires design work before implementating. severity-minor This label is used by an internal tool
Milestone

Comments

@dustinmoris
Copy link

dustinmoris commented May 5, 2020

Currently the HTTPS redirection middleware always redirects to HTTPS, however this breaks stuff when the host is not the one for which the certificate has been issued or in my case when there is no certificate because the SSL termination has happened two proxies higher up.

For example, running an ASP.NET Core app hosted in Kubernetes means that there is normally 2 proxies in front of Kestrel. One is the ingress controller, which is normally configured to use a Let's Encrypt certificate and is doing the SSL termination and then a second proxy is an internal service load balancer in front of all the pods where the apps are running.

Kubernetes checks the health of a pod by doing readiness and liveness checks, but these are being done via the internal network on a local IP address (e.g. http://10.8.0.7/healthz). If the HTTPS redirect middleware is enabled then it will try to redirect this request to https://10.8.0.7/healthz, which cannot be resolved and the service will fail the health check and get subsequently killed.

Currently one can apply a workaround fix by specifying the X-Forwarded-Proto header for the health check inside Kubernetes, which will prevent the middleware from redirecting, but that only works in some instances. Other cloud infrastructure and 3rd party services which cannot be configured to send the X-Forwarded-Proto header will still fail to health check the service.

This could be easily prevented by configuring a list of hosts for which the https redirection middleware will redirect, otherwise not.

Currently I have to run a custom middleware before the https redirection middleware and check the host and then based on the host decide if I set the Request.Scheme to https or not in order to workaround this issue, but it would be nicer if this could be configured in one middleware.

Any thoughts?

EDIT:

Basically what I want to do is to give the HTTPS redirect middleware a list of hosts for which it should redirect to https, otherwise do nothing:

  • api.example.org
  • www.example.org
  • example.org

otherwise don't redirect.

@Tratcher
Copy link
Member

Tratcher commented May 5, 2020

This looks like an expansion of #21291.

@dustinmoris
Copy link
Author

I saw that issue and I'm not sure if it's necessarily a duplicate.

There is HTTPS redirect for multiple hosts and then there is NOT redirecting for hosts except {list}.

You commented on the other issue the following:

In this example it needs to be able to redirect myhost:80 -> 443 and myhost:4567 -> 4568.

This wouldn't fix the problem which I've listed, because I want http://example.org to get redirected, but http://127.0.0.1 or http://10.8.0.1 to just be left alone and not redirected so internal health checks can just continue to work.

@Tratcher
Copy link
Member

Tratcher commented May 5, 2020

You're right. I edited my comment to clarify this is an expansion of that scenario that clarifies what to do if something isn't in the given list.

@dustinmoris
Copy link
Author

Great, thank you!

@analogrelay analogrelay added Needs: Design This issue requires design work before implementating. enhancement This issue represents an ask for new feature or an enhancement to an existing one labels May 6, 2020
@analogrelay analogrelay added this to the Backlog milestone May 6, 2020
@Tratcher Tratcher added affected-few This issue impacts only small number of customers severity-minor This label is used by an internal tool labels Nov 9, 2020 — with ASP.NET Core Issue Ranking
@Tratcher Tratcher assigned Tratcher and unassigned Tratcher Jan 7, 2021
@amcasey amcasey added area-middleware Includes: URL rewrite, redirect, response cache/compression, session, and other general middlewares and removed area-runtime labels Jun 2, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
affected-few This issue impacts only small number of customers area-middleware Includes: URL rewrite, redirect, response cache/compression, session, and other general middlewares enhancement This issue represents an ask for new feature or an enhancement to an existing one Needs: Design This issue requires design work before implementating. severity-minor This label is used by an internal tool
Projects
None yet
Development

No branches or pull requests

6 participants