Nalates wrote:I keep rereading your post looking for "The real benefit of encryption is what I mentioned above." and not finding it...
What I was referring to by “above” is
Christian Walther wrote:Knowing that only I and the server operator know what I am doing on the server, and knowing that I am connected to the server that I think I am
Nalates wrote:My thinking is that if I wanted to send instructions that would indicate my AV was kicking cones into a precise stack, or that my camera had taken a picture and was sending the image information, I would look at the server code to see what it needed, then write the data pack, encrypt it using the appropriate public key, and send it. Where does the encryption ad any additional protection once all is open?
It doesn’t. That is not the purpose of connection encryption. That falls under what Kaelis referred to as “security by obscurity” – the lack of a permissions system on the vault, the lack of input validation, etc. This is a completely orthogonal issue to whether the connection is encrypted (other than that the encryption contributes a bit of obscurity). (And there seems to be a broad consensus that it is something that needs to be addressed as soon as possible, as with fan code evolving and Cyan code being released, more and more of the obscurity is wearing off. Parts of it may have been addressed in the recent security update, I don’t know. It just has nothing to do with the encryption.)
I’m sure you are aware that the exact example of KI images you cite has been performed on MOULa, encryption or not. No knowledge of the server code is required for that, so this is not something that will change with the release of the server (binaries or source code).
Nalates wrote:But I took your posting to mean many of the game packets are encrypted.
That is correct. The connections to the gatekeeper, auth, and game servers are completely encrypted (apart from the first few packets where the key negotiation happens). The connection to the file server is not.
Mac_Five wrote:Well consider shards that develop along divergent paths - Shard-X works with a modified Client-X, Shard-Y works with a different Client-Y. Client-X maybe allows players to create Bahro avatars, but Shard-Y doesn't like that sort of thing. While the encryption per se isn't maybe essential to validate the client-server relationship the key exchange is, so leaving the encryption in makes sense.
Note, however, that this scenario is not addressed by the current system. The client is not authenticated to the server, only the other way around (as a side effect of the key exchange). Currently, any client can be used on a given shard, whether the shard operator likes it or not, as evidenced by WhoM or the Bahro players.
Nalates wrote:I feel safer... is nice but I don't see it as justification for spending CPU cycles when there is still no security. […] Is there really any serious doubt I've connected to the right server? Or even a concern?
Maybe not – but is there a reason in the other direction? The question is not if encryption should be introduced, but if the encryption we already have should be thrown out. I don’t see a cost-benefit-tradeoff here. CPU cycles? I think what you are doing here is what is known as “premature optimization”. Have you measured that the few XOR operations (and whatever else RC4 does) have any nonnegligible effect on the total CPU usage of Uru?
Nalates wrote:I would think it much faster to let the lower network functions handle encryption with a simple https protocol than encode at the higher game level.
Assuming that you mean “SSL”, not “https”, that is exactly what happens, basically (not specifically using SSL, but the same principles). The encryption sits between the TCP and game protocol layers, it’s the whole stream that is encrypted, not individual game messages.