[Request] Document Secure Connection Mode options

[jellyfin-archive]

[Request] Document Secure Connection Mode options

[PrplHaz4]

Started a table in the top post to track what is impacted when secure connection mode is changed...

[mark-monteiro]

Here's my quick investigation from only looking at the code and not doing any actual testing. This setting doesn't actually correspond to a single setting on back-end configuration, but three separate ones (code snippet here is edited from original for brevity)

                        case "proxy":
                            config.EnableHttps = true;
                            config.RequireHttps = false;
                            config.IsBehindProxy = true;
                        case "required":
                            config.EnableHttps = true;
                            config.RequireHttps = true;
                            config.IsBehindProxy = false;
                        case "enabled":
                            config.EnableHttps = true;
                            config.RequireHttps = false;
                            config.IsBehindProxy = false;
                        default:
                            config.EnableHttps = false;
                            config.RequireHttps = false;
                            config.IsBehindProxy = false;

• EnableHttps: If true, the server listens on the configured HTTPS port (there must also be a certificate specified), otherwise it does not.
• RequireHttps: If false, the server will not force redirects from HTTP -> HTTPS
• IsBehindProxy
  • If true, the server will not force redirects from HTTP -> HTTPS
  • The code is a little bit of spaghetti, but from what I can tell this property doesn't seem do to anything else.

Assuming my analysis is all correct, maybe this information is enough to get this documented for now.

I think a quick way to re-write this functionality to make it more usable would be to:

• Remove the dropdown for Secure Connection Mode
• Expose the EnableHttps and RequireHttps settings in the UI as checkboxes
• Remove the IsBehindProxy setting entirely since it appears to be redundant.
• Optionally add a validation to make sure RequireHttps is only checked if EnableHttps is also checked

[Artiume]

It looks like chromecast is also impacted by host mode in docker, not just hdhr and dlna

[Artiume]

https://github.com/jellyfin/jellyfin-web/blob/e85ea5fe1cc9c00965c6d8d1ae93b34ae9b38c71/src/controllers/dashboard/networking.js#L34-L57

How the different network modes are defined.

[Artiume]

https://github.com/jellyfin/jellyfin-web/blob/e85ea5fe1cc9c00965c6d8d1ae93b34ae9b38c71/src/controllers/dashboard/networking.js#L137-L147

Order of preference

[Artiume]

https://github.com/jellyfin/jellyfin-web/blob/e85ea5fe1cc9c00965c6d8d1ae93b34ae9b38c71/src/networking.html#L74-L81

[Artiume]

https://github.com/jellyfin/jellyfin/blob/e241f83ff12aa2231443b78d39d1db2646aebdf9/MediaBrowser.Model/Configuration/ServerConfiguration.cs#L250

Default https?

[Artiume]

Nice work

[bengalih]

As the title says - at least document the implications of changing modes...DLNA, HDHR and Chromecast appear to be impacted in strange ways.

Ref: jellyfin/jellyfin#2259, jellyfin/jellyfin#1396 (comment)

Just chiming in here as I saw your post to me on the other thread. As of my writing of the above mentioned URL, everything was working for me. I am unsure if all of my prior issues were due to problems with earlier versions, misconfigurations of the product or nginx, or my lack of understanding.

When using NGINX and an LE certificate with 10.5.2+ set to "Handled by RP", all my usage scenarios seem to work.

I am more than happy to run any tests and provide more information, so please let me know what specifically you would like me to provide.

[Artiume]

Any help testing would be greatly helpful. For myself, life is a bit busy so I've fallen back to helping with community assistance and not much actual testing.

If you want to fill out @PrplHaz4's table in the top comment, thatd be great. It'll let us see the exact behavior thats occurring.

[bengalih]

Any help testing would be greatly helpful. For myself, life is a bit busy so I've fallen back to helping with community assistance and not much actual testing.

If you want to fill out @PrplHaz4's table in the top comment, thatd be great. It'll let us see the exact behavior thats occurring.

I guess I'm a bit confused about what specifically you guys are trying to test now. Clearly the documentation is minimal (and perhaps wrong), but I'm not sure it is worth documenting the behavior of every scenario especially when/if the devs can't/won't provide what is supposed to be the correct behavior. Wouldn't it be more efficient to simply document the working configuration for a particular case scenario?

Also, to be clear I am not using Self-Signed certs anymore. While I believe in them and I believe products should work with them, the fact is that some products/OS don't work well with them as it is difficult or impossible to install root certs. That being said, most of my tests did seem to work with self-signed as well.

Also, I am using NGINX, with only port 443 (as my ISP blocks 80). So I never access my JF over 8096, everything is proxied. It was my interpretation from what the devs have previously said that they don't plan to really put a lot of effort into native HTTPS support and the recommended configuration for JF with SSL is to use a reverse proxy like NGINX. At first I didn't like this response, but now I am an NGINX convert and am using it for all apps even those with native https support that works well.

I don't really want to fully rework my entire config for sake of testing, but am happy to do some manipulation and tests. I see the charts above, but I don't entirely understand how you are performing each test (and why - based on comments above). I need more clarity on what you are trying to achieve and test (i.e. self-signed? just ssl? using specific ports? with/without nginx, chromecast functionality, android/windows client, etc)?

In short - yes, the secure connection mode documentation isn't great, but it is not worth trying to understand something the devs don't even understand (or don't want to document because they aren't really supporting it and may change at any moment - or be dropped entirely). Again, seems smarter to just say "do this if you want it to work".

But, let me know what specifically I can provide based on my setup and I'll be happy to.

[Artiume]

Also, I am using NGINX, with only port 443 (as my ISP blocks 80). So I never access my JF over 8096, everything is proxied. 

So YOU might not access JF over 8096, but Nginx IS accessing JF over 8096.

So there's three layers of concern for networking. Localhost, local network, WAN network.

Required should always require an ssl cert, so it should always use https and its own dedicated port.

Disabled only http on everything.

Preferred should be removed and never mentioned again.

Handled by Reverse proxy should use http for localhost and local Lan but use the proxy for wan.

^
If handled by RP is configured this way, it could still introduce problems for people because it assumes that one NAT jump is immediately the internet while that isn't always true (Docker bridge is one example, one NAT jump will get you to your local Lan, two NAT jumps to get to the internet).

I currently run my setup in Disabled to get my hdhr to work, but then I came to find out that it broke chromecasting.

In short - yes, the secure connection mode documentation isn't great, but it is not worth trying to understand something the devs don't even understand (or don't want to document because they aren't really supporting it and may change at any moment - or be dropped entirely). Again, seems smarter to just say "do this if you want it to work"

The issue is it's a difficult challenge to fix so many of us have moved on to fix easier issues. The more details that are provided, the faster we know how to fix it. We had subtitle issues until a community member did a deep dive to figure out the issue jellyfin/jellyfin#2507 (comment) and once this tidbit was worked out, we were able to pinpoint the issue within about 20 minutes and we had a patch within the hour lol. The more behavioral details we can collect, the easier it'll be to know how to fix it.

[bengalih]

So YOU might not access JF over 8096, but Nginx IS accessing JF over 8096.

Yes, I understand that... I mentioned that because in the chart above the preferred option shows https://:8096. I don't see an instance where you would test that configuration since all https access would go through proxy and only hit JF over 8096 http. This was just one example that to me is testing complexity that would seem unnecessary.

Required should always require an ssl cert, so it should always use https and its own dedicated port.

Disabled only http on everything.

Preferred should be removed and never mentioned again.

Handled by Reverse proxy should use http for localhost and local Lan but use the proxy for wan.

Ok, but still these are unclear why one cares/is testing? If preferred should be removed, why hasn't it? Or have the devs stated they are removing it in a future release already? Why should required and disabled even exist if an option like RP does? After all, if you are telling JF that a RP is handling all requests, then wouldn't it need to know how to communicate with that RP? Whether to send it secure or insecure data in the first place? Additionally - why would anyone want to configure https access for remote, but not use it internally as well? Also, if http is disabled, then Chrome won't cast no matter no what (Chrome requires https in order to connect to Chromecast devices)... so why would anyone who is concerned about this choose to implement http only?

Look - I'm not trying to be argumentative (and especially not to you directly) - I'm just saying that the entirety of how the options are designed seems overly obtuse. It would seem there should be a better way to design this. One could say one setting for local requests vs. one for remote, but I'm not sure how the RP would work in this design since a RP is often making a request on the same network.

If handled by RP is configured this way, it could still introduce problems for people because it assumes that one NAT jump is immediately the internet while that isn't always true (Docker bridge is one example, one NAT jump will get you to your local Lan, two NAT jumps to get to the internet).

Understood, seems similar complications that I just mention above - where it isn't enough to just say local vs. remote, there needs to be more specific configuration. I could posit some ideas for how to design it, but at this point unless the devs are soliciting feedback for that, it wouldn't be worthwhile.

I currently run my setup in Disabled to get my hdhr to work, but then I came to find out that it broke chromecasting.

I was only chiming in here because the OP commented on my other post (the one linked in the OP) asking me to provide my experiences with the newer versions of JF. I think I've pretty well documented my problems and my current configuration which seems to work for me.

I'm not using Docker, and HDHR, or really anything fancier than JF running on Windows which I connect to via NGINX running on my router. In this config everything seems to work when accessing it via 443. I can chromecast to my devices internally, I can stream to my phone remotely, I can even chromecast from my phone to a chromecast device outside my network. I totally get that others may have an additional layer of complexity (like double-NAT) which may break things.

Determining what works or doesn't isn't really going to get to the bottom of things. Someone with a particular issue is either going to need to somehow review logs and captures to see why a specific URL might be malformed for their use case, etc. Or, someone with the requisite knowledge can just look at the current code and say what will happen. I honestly don't understand why for any particular use case which should work that a bug cannot be posted and a dev/contributor can look at the code and say why it isn't working. If the devs don't have time to do that, then I guarantee there won't be time to actually fix anything. Especially since troubleshooting anything with SSL is nigh impossible in a lot of configurations since you are unable to actually view the traffic on either end - it may not be easy to see what URL (e.g.) a chromecast is getting delivered to it from JF.

I personally have not looked at the JF logs in much detail. Do the logs give detailed info every time they deliver a URL to a client? If not, perhaps a enhancement request to add that data to the logs would go a long way to troubleshooting the issue? Again...if the devs won't do that, then why think they will spend time fixing the issue either?

Again, not trying to be combative - just explaining my position on the matter. I am also still willing to help/test anything I can with my configuration, but I'm still at a loss with what the OP would like me to contribute. I've already provided a lot of details in prior posts regarding what I observed with different configurations that I could replicate.

So - if someone want to ask me specific questions on my config or ask me to test a specific scenario with my devices, I'm happy to. Otherwise, I'll leave you guys to figure this out using the methodology you've preferred to take.

[Artiume]

Or have the devs stated they are removing it in a future release already.

I'm the dev leading us on this adventure, @dkanada, @mark-monteiro and @JustAMan might be able to lend a hand if they're interested, but they have their own projects. Until we figure out what we want to do, nothing is really being done. I don't have the time to commit to defanging this by myself, there are bigger bugs and life commitments ahead of this one.

Additionally - why would anyone want to configure https access for remote, but not use it internally as well?

For myself speaking, I want to have external https access, but I don't want internal https access. I have a HD HomeRun, I don't want to attempt configuring it for https. Talk about a nightmare for little gain.

Also, if http is disabled, then Chrome won't cast no matter no what (Chrome requires https in order to connect to Chromecast devices)... so why would anyone who is concerned about this choose to implement http only?

If someone doesn't want to implement a reverse proxy and wants local use only, what would you suggest them do? Not everyone's use case is remote capability. And some might not even want chromecast capability, it is technically not a de-centralized service, it requires a service on the jellyfin.org server's to be hosted and it is a google service, two gotchas for those who want complete de-centralization.

Understood, seems similar complications that I just mention above - where it isn't enough to just say local vs. remote, there needs to be more specific configuration. I could posit some ideas for how to design it, but at this point unless the devs are soliciting feedback for that, it wouldn't be worthwhile.

I'm open to all ears, but as it is, my plan is to just fix the current setup. I would like to simplify the service by allowing you to designate the ports and protocol, but I feel like it would take a simple drop down menu and turn it into an admin's worst nightmare.

So - if someone want to ask me specific questions on my config or ask me to test a specific scenario with my devices, I'm happy to. Otherwise, I'll leave you guys to figure this out using the methodology you've preferred to take.

I need reverse proxies tested both in host mode (such as yours with windows) or bridge mode (such as with docker), to figure out what devices break and logs to show why. Same for Required. All clients tested such as cc, air play, etc, and other local devices such as HDHR's. I understand that you may not have these, just explaining what needs to be done. I'm thankful for any help that is provided, but until I have that Eureka! l won't know the exact path to take to fixing this.

[bengalih]

I'm the dev leading us on this adventure

Gotcha. Sorry I missed that. That being said - wouldn't it be more efficient to look in the code to see what the app is designed to do rather than guess or look for piecemeal second hand testing evidence of what it is doing? Of course there will be use cases that aren't expected, but a dev asking the user base to document the behavior of this seems a bit strange to me.

For myself speaking, I want to have external https access, but I don't want internal https access. I have a HD HomeRun, I don't want to attempt configuring it for https. Talk about a nightmare for little gain.

Point taken. Some internal-use apps may not be https compatible (but, more below...)

Also, if http is disabled, then Chrome won't cast no matter no what (Chrome requires https in order to connect to Chromecast devices)... so why would anyone who is concerned about this choose to implement http only?

If someone doesn't want to implement a reverse proxy and wants local use only, what would you suggest them do? Not everyone's use case is remote capability. And some might not even want chromecast capability, it is technically not a de-centralized service, it requires a service on the jellyfin.org server's to be hosted and it is a google service, two gotchas for those who want complete de-centralization.

I'm open to all ears, but as it is, my plan is to just fix the current setup. I would like to simplify the service by allowing you to designate the ports and protocol, but I feel like it would take a simple drop down menu and turn it into an admin's worst nightmare.

If someone wanted local only, why would the implement https at all? Just set it disabled and end of discussion, no?
OTOH, what if someone wanted to disable https because of HDHR (or simplicity), but needed https for local because of Chromecast? It appears the mobile JF app does not require https to cast to a local device, but Chrome does. The point is that there are so many use cases that I still question expending effort fixing the current system. Wouldn't time better be spent implementing a system where we can control returned URL based on IP or certain headers? Or better document how to configure reverse proxies to rewrite the requests to do these things?

I need reverse proxies tested both in host mode (such as yours with windows) or bridge mode (such as with docker), to figure out what devices break and logs to show why. Same for Required. All clients tested such as cc, air play, etc, and other local devices such as HDHR's. I understand that you may not have these, just explaining what needs to be done. I'm thankful for any help that is provided, but until I have that Eureka! l won't know the exact path to take to fixing this.

Again, still happy to help. I am however unsure what additional tests I can do that I haven't already reported on. I'm also unclear on the chart at the top of the page. Perhaps you or the OP can actually make a post on testing methodology that you are looking for. If you want to go this route instead of actually just reviewing the code for actual behavior, I think this would be a requirement.

In closing (once again), I'm not trying to throw a wrench in the gears, just to bring things into overall perspective. I realize that this issue was seemingly boosted by some issues with HDHR, but if one really wants to fix the underlying issue the fix shouldn't be short sighted. If someone needs to fix one specific scenario, some more individual effort, like configuring RP rewrites is probably the better method.

As it stands, I will go ahead and just to a simple scenario test with my chromecast device on the different modes to at least provide what I think I can. Would it not be better for OP to move his chart to a wiki page so it can be edited by all?

[Artiume]

Would it not be better for OP to move his chart to a wiki page so it can be edited by all?

If it were in the official wiki, it'd require another approver to update it. As it stands, OP and myself (or anyone else of the dev team) can edit his post to update it.

In an ideal situation, a complete rewrite would be better and will probably occur one day. With that said, I'd rather fix the hdhr and chromecast issue today rather than spend a month doing network rewrites, I don't have enough hardware to test every scenario, and I could cause major regressions for situations I didn't consider and I might end up being over my head to do a full rewrite.

[bengalih]

Assuming my analysis is all correct, maybe this information is enough to get this documented for now.

I think a quick way to re-write this functionality to make it more usable would be to:

• Remove the dropdown for Secure Connection Mode
• Expose the EnableHttps and RequireHttps settings in the UI as checkboxes
• Remove the IsBehindProxy setting entirely since it appears to be redundant.
• Optionally add a validation to make sure RequireHttps is only checked if EnableHttps is also checked

Great first look, good info. Taking all your assumptions as fact for now...
This still won't fix any actual functionality for anyone will it?
Based on what you state right now aren't all possible combinations accounted for? In all cases where https is set to enabled:

                        case "proxy":
                            config.EnableHttps = true;
                            config.RequireHttps = false;
                            config.IsBehindProxy = true;
                        case "required":
                            config.EnableHttps = true;
                            config.RequireHttps = true;
                            config.IsBehindProxy = false;
                        case "enabled":
                            config.EnableHttps = true;
                            config.RequireHttps = false;
                            config.IsBehindProxy = false;

We have a false/true, true/false, and false/false combination of the RequireHttps/BehindProxy tuple.
Only one missing is a true/true, but would this cancel each other out?
I have to think that the IsBehindProxy code does something else. You state:

• RequireHttps: If false, the server will not force redirects from HTTP -> HTTPS

• IsBehindProxy

  • If true, the server will not force redirects from HTTP -> HTTPS

But how would this translate for the "enabled" option? It is setting them both to false, so one must take precedence over the other, right?

In any event, even if these options are poorly worded, can we agree that currently with all of them we can find one that has the same combination of options you are presenting? If so, then I question whether simply redesigning the option list will provide any actionable solutions.

What am I missing?

[mark-monteiro]

This still won't fix any actual functionality for anyone will it?

No, I was just proposing changing the UI to make it easier to use without making functional changes. I'm not familiar with the existing networking issues. That said, I think making the config/UI simpler will make diagnosing the actual issues much easier. And this ticket is only supposed to be about documenting the existing functionality anyway.

But how would this translate for the "enabled" option? It is setting them both to false, so one must take precedence over the other, right?

I'm not 100% sure I understand your question, but the code works something like this.

if (EnableHttps && RequireHttps && !IsBehindProxy)
    DoHttpsRedirect()

There's no point having the IsBehindProxy setting when RequireHttps is sufficient. Perhaps IsBehindProxy was previously used for something that has since been removed, or perhaps the code was just poorly designed to begin with, but I can't see anything else it is functionally used for.

[bengalih]

@mark-monteiro

I totally agree that making things clearer with a more straightforward option picker might be beneficial. I just wanted to add that for those people who are tracking this from other issues (like with HDHR or Chromecast) aren't likely to get any real solution when this is done. While it may make the behavior JF performs clearer, it seemingly won't allow them any more flexibility/options than it currently does now with the 4 permutations available.

Basically we are saying that currently JellyFin can only do two things:

1. Enable HTTPS or not.
2. Enable HTTPS redirect or not (if HTTPS is enabled).

So currently, based on the code does only the "handled by reverse proxy" do both 1 & 2 or does "enabled" it also do it?

From my reading of what you wrote so far I am inferring that both should..however if so, I'm not sure that is 100% correct because I currently have the "handle by RP" setting, and I don't believe all my functionality works if I just use "enabled." I would have to go back and test that if you think otherwise because if that is the case then there would seemingly be some more stuff inside the spaghetti.

I'm pretty sure the options for LOCAL and PUBLIC http/s ports have to play into the options somewhere, right?

[mark-monteiro]

Basically we are saying that currently JellyFin can only do two things:

Yes, those are the two things this specific setting controls ("secure connection mode").

does only the "handled by reverse proxy" do both 1 & 2 or does "enabled" it also do it?

No, "enabled" does not do both, it only enables HTTPS, but does not force the HTTPS redirect. Maybe this will make that more clear:

if (EnableHttps && RequireHttps && !IsBehindProxy) DoHttpsRedirect()
if (true && false && !false) DoHttpsRedirect()

I'm pretty sure the options for LOCAL and PUBLIC http/s ports have to play into the options somewhere, right?

Yes, the other networking settings do have effects, but they don't specifically interact with the three config settings I described earlier. Here is more information on what I could determine about some of the other properties:

• PublicPort: the HTTP port used for UPnP port mapping
• PublicHttpsPort: the HTTPS port used for UPnP port mapping
• EnableUPnP: Used to enable/disable UPnP. For UPnP to be enabled, both the EnableUPnP and EnableRemoteAccess settings must be true
• EnableRemoteAccess
  • Used to enable/disable UPnP. For UPnP to be enabled, both the EnableUPnP and EnableRemoteAccess settings must be true
  • If true, turns on filtering of remote IP addresses using the whitelist/blacklist

[bengalih]

No, "enabled" does not do both, it only enables HTTPS, but does not force the HTTPS redirect. Maybe this will make that more clear:

if (EnableHttps && RequireHttps && !IsBehindProxy) DoHttpsRedirect()
if (true && false && !false) DoHttpsRedirect()

Yeah, brain fart - obviously I knew that Require would force, but not enabled...I got to bogged down looking at the psuedo-code to look at the bigger picture.

I'm pretty sure the options for LOCAL and PUBLIC http/s ports have to play into the options somewhere, right?

Yes, the other networking settings do have effects, but they don't specifically interact with the three config settings I described earlier. Here is more information on what I could determine about some of the other properties:
...

Right. And I don't want to bog down this thread with too much outside the scope of the OP, but only to reiterate that the OP seems to have been opened to document these settings to deal with certain case scenarios not working. For the larger picture I think the additional functionality would also have to include the port mappings sent in the client request. The dashboard used to display the full url including mode and port that was being used. That has since been removed since I believe it was either inaccurate, misleading, or simply confusing. However to deal with all of the required scenarios it would seem more fine-grained control over not just these settings, but ports as well. I think all the issues people are having are either because the wrong http/s method and/or the wrong port is being returned to a client.