pull down to refresh
The whitelist-only approach is definitely necessary in some environments, but I think at odds with the use of most Lightning nodes since its value is in openness. Strike and I believe CashApp did and may still do whitelist-only peers, but also somewhat unique cases being exchanges.
I know others have used proxy nodes, where their main node only peers with other edge nodes they operate.
Clankers definitely make it easier to build a whitelist, but what's whitelisted today in an open network may still need to be blacklisted tomorrow if someone finds a new exploit.
Cloudflare model is totally wrong from a centralization standpoint, a self-run reverse proxy in-front of your node would be the way to go, keeps your policy preferences private and all that.
I think I got carried away by doomposters. I just mentioned the same in #1578639. Not sure if one leads to the other here.
if such a firewall knows patterns of malicious behavior, the implementation itself would presumably have mitigation
I think the value proposition is that you can update your firewall with a mitigation faster than the devs can write and release a proper patch and you can update your node. Just restarting the node would probably take longer than updating the firewall.
you can update your firewall with a mitigation faster than the devs can write and release a proper patch
Indeed, that moves on to the next question though of how such a thing identifies those zero-days enough to mitigate them.
The kill switch flag seems like the lowest hanging fruit, that might have saved some BTCPay server users. I don't know if CLN funds were actually lost.
Stuff over and above LN is the real surface risk, LNbits has been pwned a few times, BTCPay server recently, extensions for BTCPay in the past, Blink just got hit, CoinOS a few times... and Pub has had two. These are just ones we know about.
That informs my thinking on this, there's always hot wallet risk so the the first mitigation is in size and the second is killing things whenever something is suspicious.
One thing I've considered with Pub specifically, since they're discoverable via relay, is should it be our policy to turn off our relays if there's an incident and give people a chance to patch or give us time to diagnose? Problem with that is it makes opt-out a friction path since you'd have to use non-default relays.
Then, should we make auto-updates opt-out instead of opt-in? They're currently opt-in since opt-out is blind trust in our repo and github... but I'm now leaning towards I'd rather catch shit for that than someone naive losing sats they didn't have to.
My first reaction is why would you want all the overhead of packet-level inspection, but I suppose the granularity/adaptiveness of policy you could apply makes the idea interesting.
Cloudflare model is totally wrong from a centralization standpoint, a self-run reverse proxy in-front of your node would be the way to go, keeps your policy preferences private and all that.
That reverse-proxy, maybe running something jev-like that takes in node state context, becomes a matter of sharing policy templates. A repo for templates for such a tool is imo more valuable than a service.
A local clanker can also cron check upstream for security critical stuff, tweak templates based on local context, etc... keeping behavior much more personal.
Bit of a chicken and the egg problem too though, if such a firewall knows patterns of malicious behavior, the implementation itself would presumably have mitigation. Would be helpful to think about examples of how it would identify zero-day behavior as malicious, and to what extent that evolves into a web of trust re: bad IP's/keys.