Have http option

[i00]

Is there an existing issue for this?

• I have searched the existing issues

Is your issue described in the documentation?

• I have read the documentation

Is your issue present in the nightly release?

• This issue is present in the nightly release

Describe the Bug

It would be good if there was the option to just use HTTP instead of HTTPS.
I use a reverse proxy and want it to manage the certificate; to do this it needs to be http only internally... I then firewall it so only the reverse proxy can access it!

Expected Behavior

No response

Additional Context

No response

Host Operating System

Windows

Operating System Version

Windows 11

Architecture

64 bit

Sunshine commit or version

0.16.0

Package

None

GPU Type

AMD

GPU Model

Radon

GPU Driver/Mesa Version

31.0.12027.7000

Capture Method (Linux Only)

No response

Relevant log output

No response

[ReenigneArcher]

I've not tested this, but you can use a custom certificate. https://docs.lizardbyte.dev/projects/sunshine/en/latest/about/advanced_usage.html#network

[i00]

I want no cert as it will be entirety managed by the reverse proxy and the firewall on the host prevents anything from accessing the HTTP page directly.
This way I can also have it automatically sync my cert as I do with every other web service I have running on my PC.

[i00]

In my opinion https should either be forced or at the very least, http disabled unless turned on by advanced configuration.

I agree with turning off a "https only" option that defaults to on.

But in my case it is not accessible directly from outside my own PC; only through a reverse proxy that is installed on the machine, this talks to a server which issues appropriate certs to a variety of services running across multiple computers on my network.

If I want to change the domain I can literally do that on my server and it will update the DNS entries on my network and issue a new cert to the computer etc; I don't need to update anything on the computer itself.

Reversing proxying to a https service is not ideal in my case as it wants to use the cert that the service has attached... if I did this for every service I had I would need to update 23 certs across things manually every 3 months!

[gschintgen]

A plain http would be a welcome addition. In particular since self-signed certificates don't provide that much protection anyway (no true protection against man-in-the-middle). Additionally browsers nowadays make it more cumbersome to add permanent exceptions when opening a page with self-signed cert. I could wire it all up as a subdomain of my private domain and use an actual letsencrypt certificate as I do for other services, but that's too much hassle for a service that I only use locally or through vpn.
(I concur that it should still default to https though.)

[gschintgen]

Hmm, except of course if the https connection is also used by the client to initiate the stream (and is not only intended for the web ui). And that is probably the case, so a plain http connection wouldn't really work anyway. (But I did not inspect the code nor sniff the ethernet traffic.)

[ReenigneArcher]

Parts of the code are http, other parts are https as we're replicating GFEs behavior.

[zaggynl]

Had a go at using sunshine behind nginx but on using the http port I end up with a page saying:

<root status_code="404"/>

I guess using sunshine behind nginx is currently not supported?

Edit: disregard, used https port and all appears to work!

[wisplite]

It would be really helpful if this could be added. I want to put the webui behind a Caddy reverse proxy, but it fails because the server is passing two certificates. Right now I have to just expose the port to the internet and connect with my direct IP, because my domain is a .dev domain which has forced HSTS, meaning self-signed certificates cannot be used AT ALL to connect to the website.

Caddy normally handles this by getting me a Let's Encrypt cert to access the website, but as previously stated I can't use it because there's no option to remove the self-signed cert. This is a security nightmare.

[alchemyyy]

This caddy config is working for me.

sub.domain.com {
        reverse_proxy https://LocalSunshineAddress:47990 {
                header_up Host {http.reverse_proxy.upstream.hostport}
                header_up X-Real-IP {http.request.remote}
                header_up X-Forwarded-For {http.request.remote}
                header_up X-Forwarded-Proto {http.request.scheme}
                transport http {
                    tls_insecure_skip_verify
                }
        }
}

[Azuriye]

Any update yet regarding this change? It will be helpful to default to http and if needed https with a certificate will be an option instead of disabling either of them outright.

[ReenigneArcher]

This is not planned. HTTP is not secure, and since gaining access to the web UI can allow a complete takeover of your system (possibly your network), there is little chance it will be an option.

[Nonary]

Not to mention you can easily fix this in any reverse proxy out there by just doing proto headers

[arpinfidel]

I agree that it shouldn't be the default. But how exactly would adding an option make it less secure? Those who go digging into those options are probably trying to use their own certs anyway

[wisplite]

I'd like to add back into this conversation by pointing out that using proto headers and stuff to work around this isn't always an option, because again, browsers WILL NOT connect to an HSTS namespace domain with a self-signed cert. .dev is a popular example of such a namespace. HSTS secured namespaces require a cert from a certificate authority like Let's Encrypt.

Because I am unable to remove the self-signed cert, it is unable to be proxied because it doesn't match the Let's Encrypt provided cert from caddy, causing the browser to think there is an attempted MITM attack and block the connection. As such, I am forced to forward unnecessary ports and connect directly via IP, which is both less secure and less convineint than if I could reverse-proxy it and put it behind CloudFlare.

As far as I see it, at least adding an option to allow unsecured HTTP connections on localhost is necessary to make this functional on some namespaces.