Security Model

Authentication Layers

The relay chain uses two independent authentication layers:

┌──────────────────────────────────────────────────────┐
│ Client to C: Trojan auth (SHA-224 user password)      │  End-to-end
├──────────────────────────────────────────────────────┤
│ A to B: Relay handshake auth (SHA-224 relay password) │  Per-hop
│ B to B: Relay handshake auth (SHA-224 relay password) │
└──────────────────────────────────────────────────────┘

End-to-End Authentication

• Client authenticates to exit server C through the tunnel
• Uses the standard Trojan protocol (SHA-224 of user password)
• Relay nodes cannot read or modify this authentication

Per-Hop Authentication

• Each relay node independently verifies the upstream relay password
• Uses SHA-224 hashing, same as Trojan protocol
• Relay passwords are separate from user passwords
• Each relay node can have a unique password

TLS Strategy

Why Skip Certificate Verification?

Between relay nodes, certificate verification is intentionally skipped because:

1. Relay nodes use auto-generated self-signed certificates
2. Authentication is handled by the relay password, not certificates
3. The client's end-to-end TLS to the exit server provides the real security guarantee

Privacy Guarantees

• Entry node knows the client IP but not the password or target
• Relay nodes only know the previous and next hop addresses
• Exit node knows the target but not the client IP (sees A's IP or B's IP)
• Application data is encrypted end-to-end between client and exit node

Best Practices

1. Use unique relay passwords for each relay node
2. Use TLS transport for hops over public internet
3. Use plain TCP only on trusted networks (localhost, WireGuard)
4. Deploy relay nodes in different jurisdictions for traffic analysis resistance
5. Rotate relay passwords periodically