HTTPS on Port 443 fails (Ubuntu)

[TheDreadPirate]

Are you saying JF hasn't implemented protection against OWASPTOP10 attacks and similar like i.e. input validation and so on? Is this what you mean with "not hardened"?

I don't know what exploits or attacks, specifically, Jellyfin is vulnerable to.  We address security vulnerabilities that we are aware of that directly affect Jellyfin, like ensuring that authentication cannot be bypassed.  But when it comes to how Jellyfin handles HTTPS, specifically, there is zero configurability regarding what ciphers to allow, server vs client cipher preference, etc.  Nor does Jellyfin make claims to being secure with the way it handles HTTPS.  Which is why we very very explicitly say to use a reverse proxy when setting up HTTPS for remote access.

How can changing a port make an application more or less secure? When it comes to ports, the question is, who can access which IP in which network segment on which port from where using which protocol. This is what firewalls are for. In my case JF is running on a VM in a non public routed network segment. So no access for any sort of pirates :-).

Script kiddies and low effort hackers typically scan common service ports.  21 (telnet), 22 (ssh), 80 (http), 443 (https), 3389 (RDP), 8080 (common alt http port), 53 (dns), etc.  Less common services are usually not scanned and any that bother to randomly scan ports will only try a few random ports before moving on.

By having Jellyfin on port 80/443, you are increasing the visibility of Jellyfin.  Which, as I said, makes no claims to be secure.  Even if someone exposes Jellyfin directly to the Internet on its original port 8096, we still strongly discourage that.

Let a hardened reverse proxy handle external connections and don't expose Jellyfin directly to the Internet if you don't have to.

Your firewall doesn't mean anything since you are allowing unsolicited traffic in on whatever port Jellyfin or your reverse proxy is listening on.  So it is up to the app running on that port to be secure.

If I get you right, you suggest to bind JF only on the loopback adapter, not exposing any of its ports on the public interface of the machine and then have a reverse proxy running on the same machine which on the second leg is talking to JF over http on the loopback adapter and is binding https on the public leg on i.e. port 443? Furthermore, in case there should be no application security, on the reverse proxy we also should have running an deep inpection firewall i.e mod security.

Just to make sure we have the same understanding: Running JF on Host A with http on a port other than 80 and having a reverse proxy running on host B, would leave all traffic between A and B unencrypted. This indeed would be a major concern, as in this case i.e. user passwords would be transmitted unencrypted. So in a scenario like this, https or any other kind of secure tunnel between A and B would be required.

No, you do NOT need to bind Jellyfin exclusively to the loopback interface.  You could, but you don't have to.  If Jellyfin is on port 8096, the reverse proxy would send traffic on that port.  That COULD be the loopback, but doesn't have to be.  And clients would connect via the reverse proxy.

If the reverse proxy is on another host on the same LAN, assuming the LAN is your home network, the traffic being unencrypted between the proxy and Jellyfin is not a concern.  If the reverse proxy is on a host outside of your LAN, the preferred method to protect that leg is to use a VPN like wireguard.  This ensures that ONLY the reverse proxy can communicate to Jellyfin.

All of this only applies if you plan to access Jellyfin outside of your network.

If you plan to only access Jellyfin from the same LAN the server is running on, none of this applies.  Running Jellyfin on port 8096 is preferred in this situation since most clients will attempt a connection on that port when http is specified as the protocol and no port is defined in the URL.