📅 Original date posted:2015-10-20
📝 Original message:
Anthony Towns <aj at erisian.com.au> writes:
> On Mon, Oct 19, 2015 at 10:51:52AM +0200, Mats Jerratsch wrote:
>> Hm interesting. So far the IP-PubKey-Relationship was public for me
>> (furthermore, I even think about adding it to the gossip protocol, see
>> other post).
>
> Yeah, it's definitely easier to think about that way.
>
>> I think we can mitigate the risks associated fairly well. Suppose
>> lightning nodes run on dedicated machines, firewalled against any
>> incoming connections (except ones on the lightning port).
>
> (I don't think lightning wallets can realistically run on dedicated
> machines/IPs; so that makes a significant distinction between wallets
> for consumers and nodes for routing/merchants I think)
>
>> Against MITM and eavesdropping your pubkey to a stranger connecting to
>> your node, we can change the protocol such that the one initiating the
>> connection always sends his signed pubkey object first.
>
> I don't thnk that works -- if you can MITM Alice and Bob, then you just do
> that while they're in the middle of a connection. When Alice reconnects,
> she immediately tells you who she is. If Bob tries reconnecting as well,
> you find out who he is too. Sending a shared secret nonce instead,
> then just sending signatures avoids that; either one can re-establish
> the connection if they can actually talk, and if there's a MITM they
> reveal nothing, but do discover they can't talk.
Having a session nonce does help after first handshake, though it allows
correlation, so it needs to change (pretty trivial, it could just be
sha256() of some shared secret plus a number which increments on each
successful handshake).
In practice I think "successful handshake" is a bit vague, so may
require allowing +/- 1 nonce. I'd have to think harder about this
though.
Is this overcomplicating things?
Coffee....
Rusty.
Rusty Russell [ARCHIVE] /
npub1zw…hkhpx
2023-06-09 12:44:54
in reply to nevent1q…sejk
Author Public Key
npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpxPublished at
2023-06-09 12:44:54Event JSON
{
"id": "ea88d25875a9a1563da82eb48e89fc0a3fd709ddab71d2fc1a0e10fdfa936526",
"pubkey": "13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425",
"created_at": 1686314694,
"kind": 1,
"tags": [
[
"e",
"3349bac3c0093cc138cf165a35e427e33b66da31c2652f9bf128f3286a54941b",
"",
"root"
],
[
"e",
"d9b71c7e62a1a03ca1c3e35d3ae7b796d551aa0599bf60b1d4567ea5918600f9",
"",
"reply"
],
[
"p",
"f0feda6ad58ea9f486e469f87b3b9996494363a26982b864667c5d8acb0542ab"
]
],
"content": "📅 Original date posted:2015-10-20\n📝 Original message:\nAnthony Towns \u003caj at erisian.com.au\u003e writes:\n\u003e On Mon, Oct 19, 2015 at 10:51:52AM +0200, Mats Jerratsch wrote:\n\u003e\u003e Hm interesting. So far the IP-PubKey-Relationship was public for me\n\u003e\u003e (furthermore, I even think about adding it to the gossip protocol, see\n\u003e\u003e other post).\n\u003e\n\u003e Yeah, it's definitely easier to think about that way.\n\u003e\n\u003e\u003e I think we can mitigate the risks associated fairly well. Suppose\n\u003e\u003e lightning nodes run on dedicated machines, firewalled against any\n\u003e\u003e incoming connections (except ones on the lightning port).\n\u003e\n\u003e (I don't think lightning wallets can realistically run on dedicated\n\u003e machines/IPs; so that makes a significant distinction between wallets\n\u003e for consumers and nodes for routing/merchants I think)\n\u003e\n\u003e\u003e Against MITM and eavesdropping your pubkey to a stranger connecting to\n\u003e\u003e your node, we can change the protocol such that the one initiating the\n\u003e\u003e connection always sends his signed pubkey object first.\n\u003e\n\u003e I don't thnk that works -- if you can MITM Alice and Bob, then you just do\n\u003e that while they're in the middle of a connection. When Alice reconnects,\n\u003e she immediately tells you who she is. If Bob tries reconnecting as well,\n\u003e you find out who he is too. Sending a shared secret nonce instead,\n\u003e then just sending signatures avoids that; either one can re-establish\n\u003e the connection if they can actually talk, and if there's a MITM they\n\u003e reveal nothing, but do discover they can't talk.\n\nHaving a session nonce does help after first handshake, though it allows\ncorrelation, so it needs to change (pretty trivial, it could just be\nsha256() of some shared secret plus a number which increments on each\nsuccessful handshake).\n\nIn practice I think \"successful handshake\" is a bit vague, so may\nrequire allowing +/- 1 nonce. I'd have to think harder about this\nthough.\n\nIs this overcomplicating things?\n\nCoffee....\nRusty.",
"sig": "d0b2365723418980495caf5e92f78d4c7879fef9ed5c38b86984e64db37f07da659e691db55328c899dd1bca54d2cef732059f35398911424647055bcfb9f9db"
}