Skip Navigation

Posts
4
Comments
111
Joined
3 yr. ago

  • Oh, maybe I misunderstood? It sounded like he didn't understand what advantage a "tunnel" could provide.

    If your server is behind CGNAT, you need a TURN-style "tunnel" to allow incoming connections. If you have your own remote server with a public IP, then you can absolutely use that and create the tunnel using wireguard (or openvpn, ssh, etc).

    I just mentioned CF in my blog post because it's probably the most popular solution.

    The point is, if you have CGNAT, you need to create that "tunnel" somehow if you want to allow incoming connections.

  • That's exactly the use case for "tunnels": allowing public, incoming connections behind CGNAT.

    Wireguard requires a public IP on at least one side of the connection and only allows private access. If you want to host a blog or website AND you're behind CGNAT, then a "tunnel" service is a very easy solution.

    Edit: my previous blog post on the topic: https://blog.k3can.us/posts/2025/feb/2025-02-21_cloudflarefort/

  • Sounds like you're fairly invested in this, so why not reach out to the maintainer? It shouldn't be difficult for them to offer a signed hash.

    ...But keep in mind that most images are built using base images and various other dependencies, which could all also be compromised. It might be better to eliminate docker entirely.

  • I use mTLS for Home Assistant and Navidrome.

    It's very secure, the only limiting factor is that the client apps need to support them (or you use a PWA).

  • Sorry, I think I misread the comment when I made my initial reply.

    Edit:

    If you mean the key provided for the demonstration, you could ensure that you get the correct one by checking the signature (it's signed by my personal key) or by doing the initial download through i2p or tor. Once it's added to your keyring, you maintain that same key for all the subsequent checks. Or, if you don't want to do either, you could consider it as a Trust-on-first-use system.

    The important point is that it's a layered system, rather than a single point of trust, and that once you trust it, it cannot be compromised.

  • I'll add: mTLS would only break because the client certs are typically signed by a private CA and the host is configured to only trust that specific CA (similar to the enterprise solution I referenced in the post).

    If, for some reason, the host was configured to trust all of the typical public CAs, then mTLS would theoretically share the same problem.

  • Not directly, but I believe mTLS would break if the traffic was intercepted/altered, so it sort of works to test the connection.

    mTLS requires installing a certificate on the client device, though. If you're able to do that, then you're also able to pin the correct cert or install a custom CA. This would be the "enterprise" solution, as far as I know, but doesn't work well for public sites, since you can't always configure your end-users devices.

    Edit: mTLS is still very useful, though. I use it to secure some of my services. It just doesn't solve this specific problem.

  • Selfhosted @lemmy.world

    Don't Trust, Verify (or: Validating Origin and Integrity without Public CAs)

    blog.k3can.us /posts/2026/aug/donttrustjustverify/
  • Really depends.

    It'd be massively overkill for me, so even if it's technically a "good value", it doesn't make sense to buy one if my cluster of $60 thinkcentres is chugging along without an issue (and I get HA).

    On the other hand, if you need all that extra performance for something, then it's probably a great buy (hence its popularity here).

  • I use beets to add synced lyrics to my library automatically.

    To display them in the web browser interface, click the lyrics button (looks like a book).

  • Have you explored any other options?

    Yeah. I briefly explored some other possibilities in the post, including a potential self-hosted option, but ultimately landed on CF as a practical compromise.

  • Selfhosted @lemmy.world

    Creating a "maintenance" page for my self-hosted sites

    blog.k3can.us /posts/2026/jul/maintenancepage/
  • Crowdsec does it by using crowd-sourced blocklists (hence the name). So if an IP triggers a scenario on other machines, that malicious address will be proactively added to your blocklist before it ever gets a chance to impact your machine.

    That is the big advantage of crowdsec over reactive-only solutions, like fail2ban.

  • What is the advantage of this over just dropping HTML files onto a USB drive?

  • Not often, but there's a niche. I wish I could remember the details, but I saw someone earlier this year that was hosting a public BBS on a c64.

  • Same experience. 🫤

  • Personally, whenever I need to process anything text-based, I use perl.

    Read the json into a hash, parse the values if desired, then plug the values into an html template.

    It's pretty quick to write, much easier to learn than python (in my opinion), and super powerful.

  • I'm a bit torn on the hardware bit, myself.

    On one hand, hardware is a fundamental aspect of self hosting. There's already a portion of the community who considers self-hosting to include using commercially-hosted cloud services (as long as it's not Google), so prohibiting hardware discussion just reinforces that concept. Plus, it can be really fun to see what creative hardware people come up. I'm pretty sure I posted about my Fediverse server running on a WiFi router here, for example. The focus was on the unusual hardware, but it was also clearly related to self-hosting.

    On the other hand, looking at what is posted in other communities, I don't think there's a ton of value in seeing a dozen photos of a bone-stock rpi or a closed laptop sitting on a desk. Same with the nth post asking if their 30-year-old 1u would be a good choice for Jellyfin; so I see why the rule exists.

    Overall, though, I think hardware should be allowed, but maybe add a rule along the lines of "if you're posting a question, please include what resources you've already reviewed or troubleshooting steps you've already taken."

    Heck, that might be a good rule for all questions, regardless of topic...

  • Selfhosted @lemmy.world

    A sneaky demonstration of the dangers of curl bash

    blog.k3can.us /posts/2026/feb/dontcurlbash/
  • Selfhosted @lemmy.world

    Running GoToSocial on an old wifi router