• 15 Posts
  • 3.16K Comments
Joined 3 years ago
cake
Cake day: June 15th, 2023

help-circle


  • I mean, Valve is doing the minimum copy protection for keeping both players and studios happy.

    Let’s not forget that Valve also has a dedicated device, the Deck, and it uses the same minimal methods as the PC version. It has a standard configuration out of the box because that makes sense for a pre-built device, but they allow you to hack it to your heart’s content.

    Meanwhile there are companies that feel the need to host their platform on completely locked down devices, like Sony/Microsoft/Nintendo, and invalidate your games on older devices so you’ll buy them over and over again, and make you pay for Internet access etc.

    There’s also companies like Epic whose game store app on PC are very invasive.

    So yeah, Steam is not completely open, but it’s as good as it gets. There are much worse ways of doing things.


  • I recommend taking a look at the new Tailscale access controls > policies (aka “grants”). Much easier to understand than their old ACLs. You can quickly draw up rules that only let specific devices access specific nodes and even only specific ports.

    There’s one small potential point of confusion, in that you can’t use node names directly in the rules. You have to go to access controls > definitions > hosts and make up a name there assigned to the node IP address, and then you can use that name in a policy.

    In other words, even if you already have a tailnode called “nas” with a fixed IP, you can’t just say “nas” in a policy. You have to go to hosts, define one called “nas” that points to that tailnode’s IP, and then you can use “nas” in the policy… 🤪

    I understand the logic, which is that hosts and definitions in general are much more powerful and can define IP netmasks and IP groups and then you can use those groups in policies… but boy, the redundancy when you have to do this for single nodes that are already assigned a name and an IP is rubbing me wrong.


  • It’s very easy to make a custom CA and issue certs. Here’s a good tutorial.

    Unfortunately in practice It depends greatly on what’s on the other side (the client app). Some examples:

    • DAVx5 on Android works perfectly fine and uses the client cert from the system store. 10/10, this is how all apps should work.
    • Ntfy on Android works perfectly fine but wants the client cert file loaded in the app, it doesn’t use the one loaded in the system store. This sucks because instead of loading a cert into the system store once and then deleting it you have to keep the cert file around for this kind of apps, in Android shared storage, which is accessible to all apps.
    • Same for Immich, wants the cert loaded in the app. Also, it will randomly lose it (on both iOS and Android). Yes, you heard that right. So it’s basically useless and I had to resort instead to a key in a custom HTTP header; which isn’t exactly the same as mTLS, but helps secure the service at reverse proxy level so it’s better than nothing.
    • Firefox on Android will use the cert from the system store, and then it will crash. Again, useless.

    Oh did I mention how you get a mTLS client cert to an app on an iOS device? You send it over email to an account that the device has access to through the Mail app, then share the attachment. Yep.

    It’s also not exactly straightforward to use mTLS with reverse proxies.

    Let’s take for example Caddy and say you want unconditional mTLS for all reverse proxy hosts. Easy enough:

    tls /path/to/domain-cert/fullchain.pem /path/to/domain-cert/privkey.pem {
      client_auth {
        mode required
        trust_pool file /path/to/custom/ca.pem
      }
    }
    

    But suppose you don’t want unconditional mTLS, you’d like to let clients in if they have mTLS or a custom header, or do different things depending if the client has valid mTLS or not. Does Caddy offer a built-in conditional to act on mTLS status? Nope!

    As a workaround I’m setting the client_auth mode to verify_if_given and then using a DIY conditional that checks if the variable http.request.tls.client.certificate_der_base64 is empty or not. But it’s undocumented so who knows if it may break at any point.

    For reference, how you handle both custom headers and mTLS at once (after setting the mode as I’ve mentioned):

    @immich host "whatever.example.com"
    handle @immich {
      @not_authorized {
        not header X-Custom-Pass "LONGRANDOMKEY01" # jim
        not header X-Custom-Pass "LONGRANDOMKEY02" # bob
        vars_regexp {http.request.tls.client.certificate_der_base64} ^$
      }
      error @not_authorized 403
      reverse_proxy http://immich.lan:port
    }
    

    The nested “not not” is required because Caddy can only do logical AND in group conditionals, so to do logical OR you basically have to do NOT (NOT a AND NOT b).












  • I keep seeing “escape the container” mentioned like it’s a very common occurance. Is it really? I’ve looked up escape CVE’s and they seem to be few and far apart, they’re usually tricky to pull off, and when one comes out it’s a big deal and they get fixed right away (obv).

    Actually my issue isn’t “do escape CVE’s exist”, it’s more like, should I really waste my time planning for it? It’s like planning for file permissions not to work, or logins to be bypassed.

    I get that shit happens and why defense in depth is a thing but how do you defend from something so fundamental? If you operate under the assumption that containerization can be by bypassed, and virtualization can be bypassed, where do you draw the line and what do you do, run each app on a standalone physical box?