2

After the player is authenticated, he receives a random, unique identification token. Every packet sent by him includes the token. A typical message would be:

token sequence_number commands

The problem is that, if somebody saw a packet, the person would be able to act as the player and give all the player's coins to somebody else for example. Or read the player's messages, or do anything short of stealing personal info.

So I thought encryption would be a requirement. But I've found many people advocating against it, one even says "it's complete paranoia" (https://gamedev.stackexchange.com/a/25551/33993).

Is there a way to avoid MITM attacks without encryption? If not, is avoiding them unnecessary?

Community
  • 1
  • 1
2013Asker
  • 2,008
  • 3
  • 25
  • 36
  • I think what you mean is "spoofing" (sending messages which appear to originate from someone else), not "man-in-the-middle" (reading and modifying the messages sent by someone else in real-time). – Philipp Jan 14 '15 at 09:54

3 Answers3

4

The linked question says, "Only if it is an in-game purchase/micro-transaction - and then why not just use something tried and true like HTTPS."

Https is regarded as sufficient for MITM protection.

By which I mean: Yes!, you should send your traffic on Https!

It will have an impact on performance, but (obviously) lots and lots of effort has gone into optimizing that. A lot of the cost happens on establishing an Https connection. For an ongoing game connection, you should be able to keep it open, and the performance impact will be lessened.

As commenters have mentioned, Https uses TLS for encryption. You can build your own TCP or even UDP protocol using TLS, as well, but these days I'd recommend if possible, use boring old TCP/Https. All the platforms have APIs for it, there's ways to make it realtimey, and it plays probably the easiest with home routers & firewalls, and will be unsurprising when you explain it to others.

See pusher and socket.io and long polling for examples of using http/https for realtime.

david van brink
  • 3,604
  • 1
  • 22
  • 17
  • 3
    TLS doesn't imply HTTP. It can be used to wrap any network protocol. – Philipp Jan 14 '15 at 09:53
  • 1
    I think that's what "david van brink" meant, @Philipp (HTTPS implies TLS (and not vice-versa) -> TLS is "regarded to be sufficient for MITM protection" so "Yes!, you should send your traffic" with TLS (instead of "on Https") would be a better use of words I guess. – jabbink Jan 14 '15 at 11:13
  • Thanks -- I've tried to clarify that distinction in the edit. – david van brink Jan 14 '15 at 17:21
  • 1
    For performance you can use both TLS (or SSL), and a weak UDP crypt for the less security-critical but more time-critical stuff. If your MMO isn't secure and inventories & accounts get stolen you'll lose most of your player base near instantly. – Stephane Hockenhull Jan 14 '15 at 17:25
1

MITM protection without encrypting the communication channel is difficult. You could use a Message Authentication Code (MAC) to protect key components from being changed. But you still need a shared secret that has to be exchanged over a different channel or using encryption (HTTPS).

You might want to take a look at the Hawk authentication scheme on how to exchange data securely over an unencrypted channel.

MvdD
  • 22,082
  • 8
  • 65
  • 93
0

Typical encryption (example: HTTPS) is not sufficient to defeat MITM (http://en.wikipedia.org/wiki/Man-in-the-middle_attack) attacks. The wiki page has a simple example of how MITM is able to defeat encryption. There are complex methods to defeat MITM but they are typically overkill for a web game.

To answer your question, encryption does not defend against MITM, but it is necessary to implement encryption as it has more to do with securing sensitive information (example, passwords, session keys etc) as it passes through the internet. Otherwise anyone listening on the network will be able to see those information in plain text.

  • http://security.stackexchange.com/questions/8145/does-https-prevent-man-in-the-middle-attacks-by-proxy-server Properly certificated https should be safe... – david van brink Jan 16 '17 at 22:04