this post was submitted on 14 Mar 2024
10 points (81.2% liked)

Selfhosted

40183 readers
557 users here now

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.

Rules:

  1. Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.

  2. No spam posting.

  3. Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.

  4. Don't duplicate the full text of your blog or github here. Just post the link for folks to click.

  5. Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).

  6. No trolling.

Resources:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 1 year ago
MODERATORS
 

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.


  1. 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"

  1. 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 are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 4 points 8 months ago* (last edited 8 months ago) (7 children)

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.

 traefik.frontend.headers.STSSeconds: "31536000"
 traefik.frontend.headers.STSIncludeSubdomains: "true"
 traefik.frontend.headers.STSPreload: "true"
[–] [email protected] 1 points 8 months ago* (last edited 8 months ago) (6 children)

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...

[–] [email protected] 6 points 8 months ago (5 children)
  1. If a user types just a domain name in the browser bar (without adding http:// or https://) the browser will try https:// first. If it sees a HSTS header it will refuse to ever access that domain over http://, period, for as long as the header says (this applies to later visits too, the browser will remember that it must not use http://).
  2. If it's the very first time the user visits your domain and they explicitly type http:// or follow a link that used http://, it depends. If they have a browser setting or addon that automatically upgrades http:// to https:// it will either put them in the first scenario silently, or issue a warning that asks them if they're sure they want to proceed non-encrypted.
  3. If they get past all these safeguards and attempt to connect to your port 80, again it depends. If they manage to connect to your server it would help if there's a redirect to https:// there but the damage has already been done...
  4. ...because if their ISP (or your ISP, or their company, or the owner of that coffeeshop WiFi they're using, or someone in their household etc. etc.) is hijacking HTTP connections, the visitor will never reach your port 80. The hijacker will connect to your 443 on their behalf and use their requests to port 80 to relay content pulled from 443, and eavesdrop on everything both ways, obtaining logins and other private info in the process.

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.

[–] [email protected] 3 points 8 months ago

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!

load more comments (4 replies)
load more comments (4 replies)
load more comments (4 replies)