Xud: Sign & verify `nodePubKey` on handshake

[kilrau]

https://github.com/ExchangeUnion/xud/issues/185 exchanges an unsigned nodePubKey for now, this task is about signing the nodePubKey packet on handshake (sender) and verifying it (receiver). If verification fails, disconnect and print according error message.

[sangaman]

This is related to #158, but I do think that virtually any approach should include signing and verifying the handshake so this will be a good first step.

[kilrau]

This is (like) a prerequisite for https://github.com/ExchangeUnion/xud/issues/158

[kilrau]

Moved to next milestone, not focus for now

[kilrau]

As discussed in the weekly call, our goal is full encryption. Hence signing and verifying the handshake is a first step, post-handshake encryption covers both - authenticity & encryption of each packet.

[kilrau]

Yes, go ahead we definitely need to sign in addition to encrypting @moshababo

Thinking more about this, we might extend this issue (can do a separate issue) to sign all p2p packets to prevent man in the middle attacks which somehow manage to hijack a socket. What do you think? @moshababo @sangaman @offerm

For encryption, I vouch for signing first and encrypt the whole packet after.

[moshababo]

For encryption, I vouch for signing first and encrypt the whole packet after.

Signing is in the messaging protocol level, so yes it should be done before the encryption (which is part of the wire protocol).
I thought of implementing the encryption similarly to BIP 151. Let me know what you think.

Thinking more about this, we might extend this issue (can do a separate issue) to sign all p2p packets to prevent man in the middle attacks which somehow manage to hijack a socket. What do you think? @moshababo @sangaman @offerm

I'm not sure it's necessary if both sides are authenticated and the channel is encrypted. I'd say it's needed only if we plan to relay messages, but not otherwise. Tell me if i'm missing something.

In regards to how to perform the actual authentication, so both sides identity will be proven:
The proof should be non re-usable, so it should be applied on session-specific data. The handshake data doesn't contain at the moment anything about the target peer.

One option could be to add the peer IP address, which will be verified by him. But this has two problems: the peer will need to verify it by its external IP address, while we permit using internal IP as well. In addition, the port wouldn't be verifiable for the inbound peer, because it's random.

Other option is to implement an interactive handshake process, and so to change our current implementation. The inbound peer knows the outbound public key, so he can add it to the handshake data, and will be expected to send his packet first. The outbound peer verifies it and then signs his handshake data which will include the received peer public key.

There might be simpler solutions then that, so let me know what you think. @kilrau @sangaman @michael1011 @offerm @ImmanuelSegol

[kilrau]

I thought of implementing the encryption similarly to BIP 151. Let me know what you think.

Yep, that sounds good.

I'm not sure it's necessary if both sides are authenticated and the channel is encrypted. I'd say it's needed only if we plan to relay messages, but not otherwise. Tell me if i'm missing something.

Correct. Let's just be alert about this if and when we allow relaying p2p packets in future.

The proof should be non re-usable, so it should be applied on session-specific data.

Sounds about right.

IP address

Additionally to all the problems you listed, it's not session-specific data. I believe that's the wrong approach.

The inbound peer knows the outbound public key, so he can add it to the handshake data, and will be expected to send his packet first. The outbound peer verifies it and then signs his handshake data which will include the received peer public key.

Public key is the better approach, but it's still lacking session data.

[moshababo]

We will make it fully session-specific by using an ephemeral key pair for the key exchange (traffic encryption) and sending it's public key in the handshake data. This needs to be done anyway.

I will work on this together with #158.