security(relay): TLS-front registration is unauthenticated — any obf_psk holder hijacks a peer's relay route #101
Labels
No labels
bug
documentation
duplicate
enhancement
good first issue
help wanted
invalid
question
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
femboy/yip#101
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
#37 hardened the UDP rendezvous path (signed
RegisterSignedverified against roots in mesh mode) but the TLS Trojan front never got that treatment.classify_first_frame(bin/yip-rendezvous/src/conn.rs:53) accepts a bare unsignedRegistergated only on knowledge of the network-wideobf_psk+ a monotonic counter (register_if_fresh_tls, no signature/cert check), thenrun_tunnel(conn_tunnel.rs:101) does last-writer-winsroutes.insert(node, tx). Any member opens a TLS conn, sendsRegister{node: VICTIM, counter: high}, and claims the victim's NodeId — all relayed frames for the victim over the TLS front go to the attacker (blackhole + traffic-analysis vantage; payloads stay Noise-encrypted). Fix: plumb the signedRegisterSignedpath into the TLS classifier and keyrouteson verified identity, not insert order. Compounds with #64/#65 (weak/unthrottled discriminator).See docs/2026-07-25-project-review-and-roadmap.md for the full review synthesis.