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.
To reply to your objections: no, encrypting channel does indeed solve the problem. After DH key exchange apart from session secret key, server would have client public key (and client would have server public key, but that is not necessary there). If malicious server terminates connection at their end, it can do that, but then it would connect to target server with its own public key, not the victim public key. What I propose there is equivalent to HTTPS with self-signed certs and using client certificates to authenticate clients.
As for this remark:
No, all communication have to be encrypted (or at least every message needs to be authenticated) because whatever complex authorization we do, malicious server can just passthrough it and takeover socket when it is done. (this would apply to my mitigation 2. too, but it is mitigated by including out-of-band information that allow victim server to tell that connection is MITMed (that obviously only works when network stack is trusted, while mitigation 3. works even with malicious network))
HTTPS needs CA for different reason, to tell that
bank.com
you connect to is really truebank.com
, and you want to be sure because you will be sending sensitive information (passwords) to it. We don't care about it, worst that can happen is that you will connect to different server than you wanted, but this shouldn't in any way enable that server to hack into your companies elsewhere.