SSL load balancer X-Header-Protocol is not honored

[sirkkalap]

Hi,

On a AWS load balancer SSL termination configuration with version v2.3.9 we are having issues with links on the pages. The links are back in the http protocol and we can not make them use https.

Given a request:

the service is responding with html having links with http:

<a href="http://digitraffic-status-test.integraatiot.eu?start_date=2017-02-18" class="links">

There must be something wrong with our nginx config inside the container.

I hope someone could see where the problem might be.

[sirkkalap]

We are still running production with http because all links have http-protocol on every page. I have not been able to fix this yet.

[GrahamCampbell]

This is intentionally not honored for security reasons. You need to add the IP of your load balancer in Cachet's trusted proxy config.

[GrahamCampbell]

By default, we ship with CloudFlare's IP. You will need to add the ones you need: https://github.com/CachetHQ/Cachet/blob/2.4/config/trustedproxy.php#L30.

[s4mur4i]

Hy,

Would it be possible to have this as an option to bypass it, and just allow any IP?

Just to give an example:
We are using cachet to monitor internal kubernetes environment, and a helm package is created for it. In the helm package the image is pointed at the docker hub image, and configuration is done via env variables.
We tested with https, but got same behaviour as above.
In our case we have no knowledge of the ELB's ip address, and at any time it can be changed, or moved to a different environment.
If we need to edit the file before deployment, that means we need to create a local "fork" build where we modify the file and create a container from it.
Using such a fork in my opinion would have more cons then pros, and would have maintainability issues.

[djdefi]

Sounds like we could maybe override this via the entrypoint.sh script and setting ENV vars.

[jbrooksuk]

By default, we ship with CloudFlare's IP. You will need to add the ones you need:

We could add this to the .env file, @GrahamCampbell. We could provide comma separated setting if needs be.

[tim-vandecasteele]

I don't know how I should implement this, as it's currently not something in the config of cachet itself, but I'm certainly interested in this, as there's no way to run cachet based on this image behind an ssl terminating load balancer. @jbrooksuk are you still considering to add this as an option?

[tonglil]

This makes Cachet completely unusable for me on GKE behind Google's HTTPS terminating LB.
There isn't an easy way to override those IPs and I won't know the IP of my LB under after deployment, making compile time setting modification out of the question).

We consciously decide not to open port 80 so that users don't send requests to an insecure port, and thus cannot set up any nginx redirects.

[sirkkalap]

Unfortunately I am not able to help Cachet to fix this. However I see this as a limitation of Docker + Cachet and not with cachet as a standalone installation.

[joecohens]

@CachetHQ/core We could just ship the trusted proxies with *, and if anybody needs special config maybe they can change it, but this will solve the docker thing. What do you think?

[djdefi]

I agree this needs to be fixed upstream. Due to https://github.com/CachetHQ/Cachet/blob/2.4/config/trustedproxy.php#L30 this would happen even on a non-docker Cachet install if I am understanding correctly.

One could also just bind mount in a customized trustedproxy.php if needed.

[tonglil]

Simply allow users to override that list with their own via an environment variable, and fall back to that list as a default if not specified. It needs to accept * though for those that fall in the situation described above.

[djdefi]

Right, but since this trusted proxy list is not part of Cachet's .env file it isn't just something that could plug straight into the existing Docker entrypoint script here.

[djdefi]

cachethq/cachet#2694 Might help with this issue somewhat.

[djdefi]

Seems to be blocked on fideloper/TrustedProxy#81 or some other upstream bit implementing it.

cachethq/cachet#2694 will help if your proxy is on one of the reserved local IP ranges.

Closing as there is nothing we can do on this side until one of the upstream projects helps support it.