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.
Random thought that came to mind, not related to your scenario:
The thing that triggered me most out of all this, why do we use the same key to "unlock" a company as RCON? I hadn't thought about this yet, but somehow that sounds a bit weird to me. So I had a thought:
What if we have keys of different "levels". As in: when you login, you use a "guest" key, one that is used for your friends-list etc. You can join a server with it (whitelist), you can do AL on companies with it, and everything.
For RCON (and admin) we have a different key. Or two even, don't know. When a server wants to know if you have rcon access, it requests your rcon key. In the client we display this as: "The server requested your administrative key for elevated access on this server.".
I have no idea if this can be implemented or is useful, but I just put it here for the world to read :)