HTTPS on Port 443 fails (Ubuntu)

[TheDreadPirate]

We're half way on the same page, half way not :-)

Re: HTTPS/TLS
I understand JF does not offer any kind of HTTPS/SSL/TLS configuration other than the port and providing the cert to be used. I know that not being able to restrict the SSL/TLS version and ciphers to be used, has to be seen as a security risk. Knowing this, it's still better to use HTTPS than to use http without encryption, sending all communication incl. passwords in cleartext. So "don't use JF HTTPS" generally is a bad advice. This needs to be formulated more differentiated.

Our advise is "use a reverse proxy if you need HTTPS".  If you need secure comms between a remote proxy and Jellyfin, use a VPN.  Wireguard is dead simple, low overhead, fast AF (on Linux), and perfect for site-to-site comms.  If your setup is local only, don't bother.  If you have someone on your local network that you are concerned about reading traffic, you should probably deal with that.

Re: Integration pattern
The only (if not using an other secure tunnel) acceptable intergration pattern allowing to use http in communication with JF would be to bind JF to the loopback adapter only and have a reverse proxy running on the same machine talking to JF on the second leg. JF then also should be configured to only take requests from the reverse proxy. This is the only way to make sure JF's http port is not exposed to the outside of the machine. Still, that's not perfect, as the http connection could be interfered within the machine. However this would most probably require to take over the machine, where intercepting a http connection isn't the main problem then.
The moment the reverse proxy is not running on the same machine, meaning communication is flowing through a virtual or physical network between the reverse proxy and JF, unencrpyted communication is a severe security risk (passwords are transmitted in clear text and can be intercepte on the network) and using https on JF on the second leg has to be considered far better than using http.

1) Only if reverse proxy and JF are running on the same machine:
pattern A: client -> https -> reverse proxy -> http/loopback -> JF/loopback
https would still be better:
pattern B: client -> https -> reverse proxy -> https/loopback -> JF/loopback

All other scenarios:
pattern C: client -> https -> reverse proxy -> https -> JF

2) If you can't have or don't want a reverse proxy running for what ever reason:
pattern C: client -> https -> JF
This pattern should not be chosen if the machine is exposed to a non-trusted, public or routed network.
However it's far better than
[dont do] pattern D: client -> http -> JF

Finally: Without knowing what SSL/TLS stack JF is using, moderns stacks are expected to support TLS configurability. From what I read in the forum, it seems to be by intention to not add configurability options to JF. Argument is, that there are reverse proxies offering this functionality, so why should JF implement it? Did I get this correct?
While I agree to this if an application runs in an application runner, I'd say it's a best practise today to encrypt communication the moment information leaves the application context. So if JF would come bundled with/in an application runner, I would agree.

Regarding 1a and 1b, if you don't need or want local clients to connect directly to port 8096 it is definitely 100% viable to only bind Jellyfin to the local loopback when the RP is on the same host.

I run Jellyfin in Docker, with plain Nginx on the host, and use "expose" in docker vs port publishing.  Since only the server is aware of the Docker IP space, I achieve a similar result.  Though not 100% equivalent since I could, hypothetically, add a route in my router to send traffic for that docker IP space to the Docker host's LAN interface.

But a lot of users do want local only clients (think Android TV and Roku) to still be able to find their server automatically via service discovery.  Which would require that jellyfin bind to the LAN interface.

1b seems overkill.  If you have something running on the server that could intercept the plaintext traffic on the local loopback, it could do the same for https since it would probably have access to the key or have access to the process or memory space to read the traffic pre-encryption.

Same with 1c.  If you have a bad actor capable of reading the traffic on your LAN, you should probably deal with that.

Having said that, I get the "better safe than sorry" mentality.  But 1c is not strictly necessary and not something an average person should worry about or bother doing.

And, for whatever reason, you can't or don't want a reverse proxy, yes HTTPS directly from Jellyfin is better than nothing.

Re: Security by obscurity
Is considered a security anti-pattern. Script kiddies or not, scanning the whole portrange of a machine is done in the fraction of a second and moving ports doesn't change anything. This is not going to make JF more or less secure.

If obscurity is your only security measure, yes.  You cannot say your setup is secure.  But it is a way to reduce risk by reducing the number of attempts.

OpenWRT supports writing dropped connection attempts to log, and then supports sending those logs via rsyslog to a remote host.  I have fail2ban read those logs to look for attempts to scan for services and then fail2ban adds an iptables rule to block the offender if they do happen to find the port my services run on.  I am intimately familiar with how script kiddies typically behave and they do not scan every port nor scan a lot of ports.  They scan common service ports, a handful of random ports, and move on.  The kid of person that would run these kinds of scans are looking for low hanging fruit.  Unpatched or EOL systems with known, often old, vulnerabilities.   I'm not saying it does not ever happen.  But it is unlikely that they will scan every port.

Code:

### router log, attempted telnet connection
2025-04-09T16:15:25-04:00 gateway kernel: [36859.043275] drop wan in: IN=eth1 OUT= MAC=<Router MAC> SRC=45.71.85.44 DST=<My IPv4 Address> LEN=40 TOS=0x00 PREC=0x00 TTL=53 ID=37875 PROTO=TCP SPT=22727 DPT=23 WINDOW=33636 RES=0x00 SYN URGP=0

### fail2ban log
2025-04-09 16:15:26,027 fail2ban.filter        [2108361]: INFO    [router] Found 45.71.85.44 - 2025-04-09 16:15:25
2025-04-09 16:15:26,029 fail2ban.actions        [2108361]: NOTICE  [router] Ban 45.71.85.44

Moving Jellyfin itself to a port that is very much going to be scanned frequently is less than ideal.  Obscurity is better than nothing.  But obscurity should be an extra step on top of a properly secure setup.  And that means using a reverse proxy for external HTTPS connections for Jellyfin.