+- Jellyfin Forum (https://forum.jellyfin.org)
+-- Forum: Support (https://forum.jellyfin.org/f-support)
+--- Forum: General Questions (https://forum.jellyfin.org/f-general-questions)
+--- Thread: Reverse Proxy (/t-reverse-proxy--3138)
Reverse Proxy - enesha - 2023-12-07
Hey all
Just a for my info kinda question. I see a lot of discussion about reverse proxy's. Im just not sure why one is necessary. Maybe it's just my setup. I come from networking by trade so maybe that's it too, and I like things the old fashioned way.
I have a linux box running JF. Works great. It is set with certbot to get and update a certificate. I have my own domain. I have replaced my ISP provided gateway with a custom pfsense box. I have it map 443 to JF. I and some others can connect to the machine over SSL just fine. I just see a lot of suggestions for a reverse proxy server, and honestly i'm not even really sure what that exactly is or why one would need one.
Is there a scenario where my setup is less than ideal and a proxy would help? Just seems like a lot of extra work. I have ssl, I have domain, I have certbot, what else is there?
Is it useful more for people running the server on windows, pi, docker, mac or whatever machines?
Just curious
RE: Reverse Proxy - TheDreadPirate - 2023-12-08
There are two benefits to a reverse proxy.
1) You can have multiple services on one port when using subpaths or subdomains.
2) Security. Jellyfin is not hardened and makes no security claims. Having a reverse proxy handling https allows a hardened application to handle the SSL/TLS handshake. Additionally, most reverse proxies give you more security options, like restricting which ciphers are allowed and adding cross origin policies.
RE: Reverse Proxy - enesha - 2023-12-08
Thanks for the reply
I am still a little unclear. Multi services one port...could be useful I suppose. I understand that JF isn't hardened, but how does that apply here? Seems like you said the reverse proxy would handle the SSL handshake and choose the cipher..ok sure, but doesn't it just pass things on to the server after that? How is that functionally more secure than having JF do the handshake is the data is then just passed through the proxy to the server? It would be the same cert, right? So after the encryption is negotiated, the proxy would just pass anything good or bad through to the server anyway, right? Perhaps taking the cpu strain of the initial encryption from the host machine and putting that on the proxy?
How would it provide more security than the hardened network appliance I use as a gateway now? I don't just hang jf off a public IP and hope for the best.
RE: Reverse Proxy - TheDreadPirate - 2023-12-08
There have been, in the past, attacks on the handshake process weaken the resulting encryption. There are also several TLS ciphers that are weak that Jellyfin still offers to clients. Jellyfin has no way to turn those off or protect against some TLS attacks (read the wiki link below). But Apache/Nginx/Caddy do.
https://en.wikipedia.org/wiki/Transport_Layer_Security#Security
I also wrote a short guide to further enhance Apache and Nginx based on industry best practices.
https://forum.jellyfin.org/t-apache-nginx-disable-weak-tls-ciphers
RE: Reverse Proxy - xaque - 2023-12-08
(2023-12-08, 08:07 AM)enesha Wrote: Thanks for the reply
Multi services one port...could be useful I suppose. I understand that JF isn't hardened, but how does that apply here? Seems like you said the reverse proxy would handle the SSL handshake and choose the cipher..ok sure, but doesn't it just pass things on to the server after that? How is that functionally more secure than having JF do the handshake is the data is then just passed through the proxy to the server? It would be the same cert, right? So after the encryption is negotiated, the proxy would just pass anything good or bad through to the server anyway, right? Perhaps taking the cpu strain of the initial encryption from the host machine and putting that on the proxy?
How would it provide more security than the hardened network appliance I use as a gateway now? I don't just hang jf off a public IP and hope for the best.
What would you do if you wanted to let's say, expose jellyseerr or jfa-go for external access. You've already mapped 443 to jellyfin, so this is where a reverse proxy comes in handy. Multiple services all behind 443.
Caddy also has a couple of geo restriction modules I find handy. You can set up geofence to block ips outside a certain range from your server, or use the maxmind module to allow/deny countries or postal codes. Very useful.
Another great use is using a reverse proxy and dns server to supply .local domains to your services.
RE: Reverse Proxy - enesha - 2023-12-09
Well I'll be honest, I've never heard of jellyseerr or jfa-go before, so there's that. I did briefly look up jellyseerr, and it mentioned a specific port, so I would probably just expose that. My pfsense firewall/router can do geo restrictions and whatever so now sure is apples to me either. Pfsense is commercial grade and runs on basically a mini PC. Multi core, 500g hd, gigs of ram. Full service appliance running DHCP, firewall, geo restrict, DNS filtering, full network protection, blah blah blah The bits about the tls weaknesses is interesting tho. Definitely something to think about, and probably the only thing that I would find useful. I would use the haproxy plugin for pfsense, so caddy or whatever doesn't really enter into it
Just not sure it passes the CBA test. But very interesting.
I read some about the tls from you Pirate, I'm look closer later. Thanks for the 411 all