[BUG] nasLogin skin (&CSS) - does not work when reverse proxying the HTTP stack

[SecuriLee]

To reproduce: Set up a Caddy instance somewhere

On your env/lib/python3.10/site-packages/opencanary/modules/data/http/skin/nasLogin/index.html file, add script to redirect page when not using your desired URL.

<script>
        // Redirect to the desired URL with HTTPS - for example if you redirect to HTTPS through a reverse proxy.  If you don't, you can remove this script section
        if (window.location.href !== 'https://rp.address/index.html') {
            // Redirect to the desired URL
            window.location.href = 'https://rp.address/index.html';
        }
</script>

The page will redirect but load blank; remove the links to the static items and it will load and display.

I do not know if this will reproduce in the same manner if you embed PEM files and go HTTPS on the Python stack itself but I am a master of laziness and redirecting via a reverse proxy with ACME seems to be more hands-off.

Ping me if you want a URL to test live, I can set it up for you with a swing from basicLogin.

[github-actions[bot]]

This issue is stale because it has been open for 14 days with no activity.

[github-actions[bot]]

This issue was closed because it has been inactive for 14 days since being marked as stale.

[jayjb]

Hi @SecuriLee,

Thanks for writing in. I just want to check something here please. Did you have the https service enabled? Because redirecting to HTTPS means that the opencanary would need to have the HTTPS service running in order to respond

[SecuriLee]

hi @jayjb the OC has no https enabled, I am being a bit cheeky by putting a Caddy reverse proxy into the Internet and doing a javascript reload of the page to display via that URL over a TLS connection. so it's a bit of a twisted setup, a proper outlier. armada.gotdns.ch is a host you could load into your browser and see my current page source and the redirect to reverse proxy. It's behind a modified basicLogin at the moment. fwiw it's a really unpopular port/protocol on my 3 OC instances 🍡

[jayjb]

Hi @SecuriLee,

The reason I mention enabling the HTTPS module for this kind of redirect (which feels like a HSTS kind of thing), is that the Opencanary (when HTTP is enabled) is likely only listening on port 80. If you redirect to port 443 (HTTPS), it is not listening on that port with a service running.

fwiw it's a really unpopular port/protocol on my 3 OC instances Which port are you trying to use or redirect to? I might be missing what you are trying to do here. Perhaps you can give me a little more information so I can try help more

[SecuriLee]

To be clear, what I am doing is having the OC listen and answer (either on 80 or 5000) and in the page there is some JS to detect that the page is not loaded using a FQDN, it redirects via a Caddy reverse proxy elsewhere on the Internet and displays the same page with HTTPS on 443.

The OC is configured only to respond on a non-TLS port; basicLogin works, nasLogin borks a little because the elements don't load properly via the reverse proxy.

I can send you some further details privately and I am happy to bounce an OC of your choosing through my reverse proxy if that helps.

[jayjb]

@SecuriLee, Ah i see what you saying. Does any warning or anything pop up in the devtool console of the browser you are using?

I seem to recall that any site being served over HTTPS (I guess even via a Caddy reverse proxy), would also need to serve the resources over HTTPS.

"When an HTTPS website references insecure (HTTP) resources, this is called mixed content. Browsers prevent an HTTPS website from loading most insecure resources, like fonts, scripts, etc. Migrating an existing website from HTTP to HTTPS means identifying and fixing or replacing mixed content."

[SecuriLee]

this could be the case but then I would expect the two Synology boxes also sat behind that Caddy to cry out. Basically the Caddy is offering TLS and then proxying to the plain HTTP port. This is the whole point of the reverse proxy, to terminate the traffic and then process the HTTP request on behalf of the client (in this case on non-TLS basis).

let me see if I can grab some console info as to what is breaking and bring this back to you. I am also happy to give you the address and let you look....let me know what makes sense.

[jayjb]

@SecuriLee, I think if you give me the address, I can also take a quick look and see if I see anything out of order. You can email me at jay [at] thinkst [dot] com if you don't want to share it here.

[SecuriLee]

Based on revisiting this issue and a discussion with Jay, I don't see it being an open issue anymore. Given no OC changes, it could have been something in the proxy. I am closing this out as I don't think it is an issue nor needs to be in a backlog.