0
\$\begingroup\$

Ive created a working authoritative client-server system using LiteNetLib for my game however im wondering if packet sniffing+modification is a real worry i should be developing for.

I read some information that other Client sniffing the packets of another client is pretty much impossible since the packets are routed through their ISP. Therefore: should i only worry about the client causing problems for the server, instead of also worrying about clients causing problems for other clients?

Currently im encrypting every packet sent by the client including movement commands such as 'move left'. My idea is that this will make packet-sniffing fail, packet-modification fail, and packet-spoofing fail.

If i remove my encryption doesn't that mean someone can spoof a packet by changing the packet source in the header? (thus sending game commands for another client - moving another player!). Usually when its encrypted i know that only the client with the secret key could have sent it, thus validating the packet source.

I see everyone saying that people shouldn't encrypt general traffic like this, but whats the truth here! Whats the best way?

\$\endgroup\$
  • 2
    \$\begingroup\$ What prevents the dedicated hacker to find your encryption algorithm and key in your client and encrypt outgoing fake packets? \$\endgroup\$ – Vaillancourt Dec 2 '19 at 17:20
  • \$\begingroup\$ @Vaillancourt yes thats something that i cant stop. BUT it does stop the dedicated hacker from tampering/seeing/spoofing other peoples packets right? Therefore the dedicated hacker can only really affect his own characters information. (i should point out every client-server connection has unique encryption key) \$\endgroup\$ – DiscreteTomatoes Dec 2 '19 at 17:35
  • \$\begingroup\$ Yes, there should not be any ways a client would know anything about another client's network information. I guess if each client receives a unique authentication key when they login, and the must provide that key with each packet they send, it'll be hard for a third party to impersonate them as they'll most likely have to "guess" the authentication key. \$\endgroup\$ – Vaillancourt Dec 2 '19 at 17:42
  • \$\begingroup\$ Nothing is impossible for a dedicated hacker, but adding the encryption will make it harder for the casual hacker. \$\endgroup\$ – Vaillancourt Dec 2 '19 at 17:42
  • \$\begingroup\$ @Vaillancourt This is a solved problem. TLS exists as an out-of-the-box solution for this very scenario. \$\endgroup\$ – Philipp Dec 2 '19 at 19:11
2
\$\begingroup\$

IP spoofing on the public Internet has become difficult because most ISPs take countermeasures to prevent it.

There isn't much one can do to screw with people's games, unless they control a router between the victim and the server. This in practice means the attacker would need to be (or have the powers to compel) an internet service provider or be on the same network as the victim and control their home router.

Unless your game is very, very competitive, most people won't bother with the logistics which are required to do MITM attacks or packet spoofing just to cheat. But there are a couple scenarios which might be worth protecting:

  • Password authentication. If you send unencrypted passwords over the Internet, they might get eavesdropped. Not only could that lead to people getting their accounts on your game stolen, they could also lose accounts on other services, because there are still people who reuse passwords (even if they really should not).
  • Real money trading. Does your game allow players to trade? Trade items which are so rare that people might pay real-world money for them? Then you need to secure those transactions, or people will try to perform MITM attacks to steal items from players.

For those reasons, adding encryption to your network protocol certainly doesn't hurt. Howerver, remember the golden rule of cryptography: Never invent your own crypto! Use tried and true algorithms and protocols, invented and implemented by people who know what they are doing. One out-of-the-box solution for this very scenario is TLS. One nice thing about TLS is that it starts every connection by exchanging an unique cryptographic key for that session. And that exchange happens in a very clever way so it can not be intercepted. That means one client doesn't have the knowledge to eavesdrop or impersonate other clients.

\$\endgroup\$
  • \$\begingroup\$ I see alot of people mention (D)TLS, my current approach is to use a Diffie-Helman c# library to create these key materials and exchange them insecurely using UDP packets. But the big question is how do i implement this DTLS? is it a library? is it offered by .net? Do i implement the protocol myself? where do i even begin in c# near the socket level? \$\endgroup\$ – DiscreteTomatoes Dec 2 '19 at 19:48
  • \$\begingroup\$ im also using a networking library called LiteNetLib which ensures reliable udp packet delivery + this combined with the diffie-hellman library. Since im using this networking library, this means i have to rely on them to implement a proper DTLS? \$\endgroup\$ – DiscreteTomatoes Dec 2 '19 at 20:08
  • \$\begingroup\$ @DiscreteTomatoes I am not familiar with that library, so I can not tell you what cryptography features it got and if they are holding their promises. \$\endgroup\$ – Philipp Dec 2 '19 at 20:39
  • \$\begingroup\$ The library doesn't offer any sort of those features im just implementing it i guess. But thanks alot for your help! i got the gist of it now. All is good. I believe my approach is sufficient for its purpose :) \$\endgroup\$ – DiscreteTomatoes Dec 2 '19 at 21:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.