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.
Okay, this is not how I understood your initial one-liner; I assumed you meant something else, but this is something we can agree on: the encryption is not the important part, but the authenticity of the packets is. Commonly this is rather difficult to setup correctly btw, but I see libhydrogen has an exchange for this; so that might be doable. I am not sure how good it is, as it strongly depends on how they implemented it, and as such I do not know how MITM resistant it is ;)
Either way, I think there are two things at play here:
is the initial scenario likely and do we need to mitigate it? My answer to that is a very simple: it is very unlikely and has a very low impact. It requires a crazy amount of social engineering. Can it be done? Yes. Is it like to happen? Well, I am sure you will try now :P So let me put the amount of times it was successfully done at 1. Especially if we split RCON keys from login keys, that mitigates the risk even further. This is how I balance the risk, YMMV.
you want to encrypt the protocol fully between client and server. This is always a good goal to have, but let's not do it because we see this scenario as the reason to do it. Let's add encryption because it is a good thing to add! That makes it a lot easier for anyone to process, and requires less babbling about: does it really solve NNN ;) Just easier, and sooner or later we need it anyway!
That does means there is a choice in order of implementation: either do the encrypting of the client <-> server traffic first, or build the authentication first.
I think, and correct me if I am wrong, that they are pretty separate from each other. Encryption gives you pubkeys, I think there might be the overlap, but I leave that judgement to you.
Encryption will require a whole different form of testing than authentication. So please look carefully how you want to PR this; I have closed more than one PR in the last few weeks as they became too big for us to process, and in result nobody really did anything with it for 2 years. That is partially on us, as developers, but you can help avoid it by keeping things in small-ish chunks that can already be validated and merged :) Especially merging encryption will be a tough process. Just something to keep in mind please!