Hej everyone. My traefik setup has been up and running for a few months now. I love it, a bit scary to switch at first, but I encourage you to look at, if you haven't. Middelwares are amazing: I mostly use it for CrowdSec and authentication. Theres two things I could use some feedback, though.
- I mostly use docker labels to setup routers in traefik. Some people only define on router (HTTP) and some both (+ HTTPS) and I did the latter.
- labels
- traefik.enable=true
- traefik.http.routers.jellyfin.entrypoints=web
- traefik.http.routers.jellyfin.rule=Host(`jellyfin.local.domain.de`)
- traefik.http.middlewares.jellyfin-https-redirect.redirectscheme.scheme=https
- traefik.http.routers.jellyfin.middlewares=jellyfin-https-redirect
- traefik.http.routers.jellyfin-secure.entrypoints=websecure
- traefik.http.routers.jellyfin-secure.rule=Host(`jellyfin.local.domain.de`)
- traefik.http.routers.jellyfin-secure.middlewares=local-whitelist@file,default-headers@file
- traefik.http.routers.jellyfin-secure.tls=true
- traefik.http.routers.jellyfin-secure.service=jellyfin
- traefik.http.services.jellyfin.loadbalancer.server.port=8096
- traefik.docker.network=media
So, I don't want to serve HTTP at all, all will be redirected to HTTPS anyway. What I don't know is, if I can skip the HTTP part. Must I define the web entrypoint in order for redirect to work? Or can I define it in the traefik.yml as I did below?
entryPoints:
ping:
address: ':88'
web:
address: ":80"
http:
redirections:
entryPoint:
to: websecure
scheme: https
websecure:
address: ":443"
- I use homepage (from benphelps) as my dashboard and noticed, that when I refresh the page, all those widgets take a long time to load. They did not do that, when I connecte homepage to those services directly using IP:PORT. Now I use URLs provided by traefik, and it's slow. It's not really a problem, but I wonder, if I made a mistake somewhere. I'm still a beginner when it comes to this, so any pointers in the right direction are apprecciated. Thank you =)
You can skip serving 80 but good practice dictates that you should enable the HSTS header if you do that, so that browsers know to not even try HTTP.
Thank you for your answer. If I do that, can I still connect via HTTP and the browser will then redirect? I don't think I have a problem with remembering HTTPs, but my family will...
So as you can see whether you maintain a redirect on 80 or not is not very important. Ideally your visitors should never attempt unencrypted connections at all. If they do and get hijacked your redirect will be irrelevant.
Redirects on 80 to 443 are relevant if your website is old and gets a significant amount of traffic from http:// links out there, which it cannot afford to miss.
Thank you so much for your thorough answer, this is very much a topic that needs some reading/watching for me. I've checked and I already use all of those headers. So in the end, from a security standpoint, not even having port 80 open would be best. Then, no one could connect unencrypted. I'll just have to drill into my family to just use HTTPS if they have any problems.
It was interesting to see, how the hole process between browser and server works, thanks for clearing that up for me!
So are you essentially saying it’s better to not even have an entrypoint on port 80 in your config at all despite using a redirect, or would using the HSTS header still prevent someone from explicity requesting your domain via http:// entirely in your examples 3 and 4?
And is this only related to allowing external requests on port 80 because the client could potentially have their connection hijacked? If you were to allow an entrypoint on port 80 from internal IP ranges only this is not a possibility (assuming your lan isn’t compromised by some other means), right?
Thankfully, I haven’t needed to expose any services so I just use a VPN for now, but I haven’t gotten around to enabling valid ssl certs for internal traffic as an additional layer of security either. I hadn’t even considered the scenario you described, so it seems like it’s better to just go the route of https everywhere and not even use an entrypoint on port 80 regardless.
Serving 80 on the LAN should be OK as long as you have reasonable control over all the Ethernet wires and WiFi access points.
You can't control what clients do, you can only control what your server does.
In case 4 the hijacking took place before they even got to your server so it doesn't matter anymore.
In case 3, if they manage to make it to your server and you have a redirect from 80 to 443 and HSTS on 443 they will narrowly escape future hijacks. So a redirect is not technically a bad thing to have, provided you also have HSTS.
Exactly, I should have said what would the server do when clients try to connect via http:// with and without the HSTS header but I see what you mean now. Thanks for the explanation!
One more thing, to make sure everything is clear: the HSTS header only matters over TLS. Servers are not supposed to give it over plain connections (could be faked) and browsers must ignore it if it's not TLS.