Android app keeps reverting to unencrypted http

[Guest]

Hello @Luke:

I don't want to use http instead of https even inside my home network. I go to great pains to secure my environment. I keep removing the http server entry from my Android app and adding the https server back and it works. However, the next time I close and reopen the app it keeps reverting to http. In the case of the wireless clients there is a hardware interface where I can make a firewall rule change to block connections over http so presumably that will be an effective workaround which I will try, but why is the client reverting to http at all? If https is available to encrypt the traffic it should be preferred regardless of the network, or at least I should be able to define a server preference. At a minimum the app should retain the configuration.

Can I fix this without having to modify firewall rules?

Thanks.

[rbjtech 5284]

1 hour ago, andrewds said:

Hello @Luke:

I don't want to use http instead of https even inside my home network. I go to great pains to secure my environment. I keep removing the http server entry from my Android app and adding the https server back and it works. However, the next time I close and reopen the app it keeps reverting to http. In the case of the wireless clients there is a hardware interface where I can make a firewall rule change to block connections over http so presumably that will be an effective workaround which I will try, but why is the client reverting to http at all? If https is available to encrypt the traffic it should be preferred regardless of the network, or at least I should be able to define a server preference. At a minimum the app should retain the configuration.

Can I fix this without having to modify firewall rules?

Thanks.

Do you still want Emby to listen on http - or do you want to remove that option ? (probably not recommended tbh, or at least have a breakglass account that allows http incase you get into cert issues..)

[Guest]

1 minute ago, rbjtech said:

Do you still want Emby to listen on http - or do you want to remove that option ? (probably not recommended tbh, or at least have a breakglass account that allows http incase you get into cert issues..)

Ideally I will have the option to configure it to fail to start if there is a problem with the secure configuration. The logging should be robust enough that I can debug and correct the problem. Worst case adjusting a configuration file to re-enable an insecure configuration could be supported.

[rbjtech 5284]

4 minutes ago, andrewds said:

Ideally I will have the option to configure it to fail to start if there is a problem with the secure configuration. The logging should be robust enough that I can debug and correct the problem. Worst case adjusting a configuration file to re-enable an insecure configuration could be supported.

Does it let you remove the http port - either in the GUI or system.xml file ? 

Edited June 23, 2023 by rbjtech

[GrimReaper 4740]

You can try specifying LAN Networks in Settings as subnet your server/clients are not on, so actual subnet would be considered "remote", ensuring https? 

[visproduction 315]

And,
Are you seeing browser cache memory of http links?  Try clearing the browser cache and see if that fixes it.

[darkassassin07 652]

... They are seprate ports, just block the http one at the firewall of the server machine.

 

Can't revert to http if the http port is entirely unreachable. (the https port won't accept http connections)

[Guest]

Thanks for all of these potential solutions. I did mention that I can resolve this by modifying other configurations. The point is that it shouldn't be reverting to an insecure configuration.

Scoping down the 'local' network configuration to only the subnet with the server did 'fix' it, but since the distinction between local and remote networks is going to be eliminated this will ultimately need to be handled some other way.

[Q-Droid 989]

The long term solution is unknown and what you did re:subnetting is likely the simplest option right now until the devs decide and begin the changes to the networking options. We have no idea what they have in mind or how they'll implement it since both the server and clients have functionality that's is dependent on local/remote distinction.

 

[Guest]

How is that relevant to preferring insecure http vs secure http? I see no reason why the network should have any bearing on the encryption.

[darkassassin07 652]

Currently the server makes a distinction between lan and wan clients; allowing more relaxed restrictions on lan clients. Part of that is not enforcing https on lan.

 

 

Once that distinction is removed, you will likely be able to set https required regardless of where the connection comes from as the server will no longer care where the client is.

[Q-Droid 989]

21 minutes ago, andrewds said:

How is that relevant to preferring insecure http vs secure http? I see no reason why the network should have any bearing on the encryption.

As it is now it's pretty much automatic. Clients like Android apps will fetch the network details from the server and switch to the local or remote end point. It's relevant because Emby does not give us the option to force HTTPS all of the time. I'm not saying which way is right or wrong, just that it's not an option right now within the server or apps so the solution is to force it externally or changing the network scope.

I agree with you that it should be an option and now more than ever knowing that the devs have changes coming but we don't know how those will look.

 

[rbjtech 5284]

Another alternative which may be worth exploring (and what i actually do) is using an internal reverse proxy - then you can just force a http request to https as you would via an external/dmz reverse proxy.    Personally, I'm fine with http inside my internal security zones, so I do this to avoid messing about with ports for all my internal services, but it would work for your http>https scenerio as well.  

I guess this won't change the client behaviour on what to accept, but at least all traffic could be forced to use https.

Edited June 24, 2023 by rbjtech

[Luke 42079]

It's due to the app's behavior of always wanting to get back onto the local lan whenever possible. We can look at expanding this to accommodate more use cases.