Include a target IP in handshake stage0, for fast rejection #673
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Does this leak info in the case of getting an incorrect host? i.e. an attacker controlled host? I suppose overlay IP address isn't really protected info...
|
|
@jasikpark yes I believe so, somewhat mitigated by #441 |
|
cool, thx for the link; i'll have to read up on what PSK is and what it affords 😅 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Nebula Stage0 handshakes carry the initiator's cert identity, but include no hint as to which peer identity they're attempting to connect to.
When connecting to a peer that shares the same CA, the peer will successfully complete the tunnel generation, and respond with the Handshake Stage1 packet, which includes the peer's certificate.
Only during the initiator's processing of this Stage1 handshake does the initiator discover that it's talking to the wrong peer.
This PR adds a TargetIp hint to the handshake stage 0 message. Old Nebula clients should ignore this new optional field, and new Nebula clients detect when a peer didn't include the field - so it's backwards and forwards compatible.
When the TargetIp is included, handshake_ix stage1 is updated to drop any handshake requests whose TargetIp doesn't match the current Nebula vpn IP.
I believe this handshake behavior will more smoothly handle error cases in which a Nebula client receives some stale info from a lighthouse, or where Nebula clients appear in LANs with overlapping LAN IP's.
I'm not quite sure how to test it, as the test would need to verify that a peer doesn't send a handshake packet upon receiving a handshake for an incorrect target ip. Maybe a counter for this event can be included and verified in an e2e test?