From antoine.riard at gmail.com Fri Sep 2 00:47:20 2022 From: antoine.riard at gmail.com (Antoine Riard) Date: Thu, 1 Sep 2022 20:47:20 -0400 Subject: [Lightning-dev] Proposal: Add support for proxying p2p connections to/from LND In-Reply-To: References: Message-ID: Hi Alex, Let's say the adversary targeting your high-value "LiFi" infrastructure is a nation-state sponsored hacking-group with strong capabilities (as we're seeing today in the cryptocurrencies DeFi space). This hacking group avails hundreds of bitcoins to fund channels, is able to setup thousands of sybil peers across the base-layer p2p network, has built a fine-grained knowledge of the miner mempools, controls few Internet ASNs and has bought second-hands mining chips on the market to own limited hashing capabilities. As of today, they would have a marked embarrassment on which attack pickup to target your Lightning infrastructure. They could start with an "old known" jamming attack to permanently cut your channel links from the rest of the wider network topology [0]. Or they could launch time-dilation attacks by building on BGP disruptions, until your chain view is so far in the past from the network tip that your on-chain HTLC-claiming safety reaction timers are useless [1]. Or they could exercise pinning attacks to prevent you to claim back routed HTLC, as a malicious commitment transaction sleeps in the network mempools until it's too far [2]. Or they could target your pre-0.24 Bitcoin Core full-node to provoke a memory crash thanks to a long-chain of low-work headers [3]. And I would say that's only a subset of the attack surface of a Lightning node. Considering all those factors, moving a LN implementation architecture from a single, monolithic process towards a collection of processes, where the critical components of the LN active defense security model are replicated and distributed, redundant access to the chain view guaranteed, sandboxing access between processes enforced and data flow monitored to react on anomalies, all things your #6843 would make easier, sounds a reasonable direction. I think it's needed if you aim for your infrastructure to survive strong attacks. On the LDK-side, inheriting from the adversarial thinking and safety-first mindset development culture from Bitcoin Core, we've always considered that type of scenarii since the early days and designed our software in consequence. We have been working and we'll keep working on many security/safety hardening: external signing [4], replicated chain monitoring [5], dynamic fee-bumping of time-sensitive transactions, various attack vectors mitigations [6]. All that said, we're looking forward to collaborate with the wider Lightning community on reusable security modules across implementations (e.g jamming mitigations) and wished "fix-the-annoying-holes" changes in Bitcoin Core (e.g package relay). Cheers, Antoine [0] https://jamming-dev.github.io/book/ [1] https://arxiv.org/abs/2006.01418 [2] https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-June/002758.html [3] https://github.com/bitcoin/bitcoin/pull/25717 [4] https://github.com/lightningdevkit/rust-lightning/pull/214 [5] https://github.com/lightningdevkit/rust-lightning/pull/679 [6] https://github.com/lightningdevkit/rust-lightning/pull/1009 Le jeu. 1 sept. 2022 ? 13:56, Alex Akselrod via Lightning-dev < lightning-dev at lists.linuxfoundation.org> a ?crit : > At NYDIG, we're considering ways to harden large LND deployments. Joost > and I discussed that currently, when external untrusted peers make inbound > connections, LND must verify the identity of the peer during the noise > handshake, and it must do this before enforcing any potential key-based > allow lists. This is done in the same process as the node's other critical > tasks, such as monitoring the chain. > > To reduce the attack area of the main node process, we'd like to propose a > means to optionally separate the peer communication into a separate > process: something like CLN's connectd, running separately, and the > connections would be multiplexed over a single network connection initiated > from the node to the proxy. The core of our current idea is demonstrated in > a draft PR: https://github.com/lightningnetwork/lnd/pull/6843 > > I'd love some early feedback on the general direction of this. If this > would be interesting, I'll build it out into a fully working feature. > > Thanks, > > Alex Akselrod > _______________________________________________ > Lightning-dev mailing list > Lightning-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: