attack.md

Attack

I just realized that security model as implemented in PR is broken when reusing same keypair on multiple servers.

1. Victim secures their company on legitimate server with pubkey.
2. Attacker lures victim to connect to malicious server.
3. Malicious server simultaneously connects to legitimate server and proxies KEYAUTH packets.
4. 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.

Possible mitigations:

1. 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)
2. 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)
3. Implement secure key-exchange and authenticate and encrypt all communication.

That's why I'm somewhat reluctant on going forward with pubkey PR without encryption.

Just so there is no confusion: this is completely up to you. My only request here is that we process encryption as a separate PR, so we can do all kinds of testing to see if nothing breaks. Something not for this gist, but I currently don't have another place to put it, so here we go :P (this just talks easier than IRC, honestly)

Lowering the MTU has consequences, as I believe some packets are nearly exactly full. Some other packets check for MTU size to split into multiple if needed. So we need to check those and make sure they work properly. Nothing we cannot do, just something that requires time :) I believe one of the packets was if you have full companies with maximum custom names and presidents, or something silly.

Another thing we have to validate, but don't have an active OS for anymore, is Big Endian machines. I think it should just work, as all these operations are done on bytes as far as I could see, but that doesn't mean we shouldn't validate. I guess Qemu with ppc64 will do the trick.

And I am sure more of these nasty things pop-up .. it will be "fun" to evaluate the PR, but something we need to do sooner or later anyway, so .. yeah .. let's get it over with :) But this is the reason I would prefer to have it as a single PR, without the password changes etc. As this on its own will already be a few hours if not days to test, validate, etc :)