I just realized that security model as implemented in PR is broken when reusing same keypair on multiple servers.
- Victim secures their company on legitimate server with pubkey.
- Attacker lures victim to connect to malicious server.
- Malicious server simultaneously connects to legitimate server and proxies KEYAUTH packets.
- After KEYAUTH is completed malicious server is left with authorized socket and can access the company, profit.
Of course it also applies to rcon access if we migrate it to pubkey too.
- Generate unique keypair for each IP/port. (permanently enabled privacy mode. cons: friends lists are nonviable, if somebody hosts server on dynamic IP it could lock people out periodically when IP changes)
- Client includes server target IP/port in signature, and server verifies that. (doesn't have cons of mitigation 1., but difficult to implement in practice: server might not necessarily know all valid IPs from which it's reachable)
- Implement secure key-exchange and authenticate and encrypt all communication.
More words to follow later (on encryption implementation approach and ways to implement server pubkey trust), but quickly for now:
In my opinion this attack is highly improbable, contrary to original attack described. It is another matter to lure someone you know who have rcon access on particular existing server onto your malicious server, than it is to somehow make them join wrong server in the first place and then expect they will get rcon access there. (assuming trusted network). But obviously this is subjective opinion.
Another take on this, if we consider ideal scenario of model that is currently used: network is trusted, use high-entropy passwords, never reuse them. In that case, KEYAUTH challenge scheme without DH is worse than currently used passwords! While this with DH and encryption is no-worse than passwords. That's why I'm somewhat reluctant on going forward with pubkey PR without encryption.