I'm making a game and I'm using websockets for 99% of communication. The only http(s) is on initial page load and when logging in/registering.

I'm a complete noob so correct me if I'm wrong, but SSL is only for preventing man in the middle attacks, right? None of the packets I send over websockets are "confidential". It's mostly just [packetName, xCoord, yCoord]. I can't think of any game packets I'm sending where it would matter if a third party got a hold of them (even if that person was also in the same game in the same room because everyone can always see everyone else while in the game).

I know it's generally considered best practice to just always use SSL but my game has a ton of communication back and forth between clients and server (lots of positional updates per second and I want as little delay/bandwidth/processing used as possible) so I'm wondering if it's necessary?

What is the worst thing that could happen if I don't enable wss?


2 Answers 2


(tl;dr at bottom)

Encryption is essentially free at this point, even on dial-up connections. Almost every major language has it built-in, or has a library for it, etc. The advantage of not using TLS/SSL is a very small fraction of a second start-up time, a very negligible reduction in CPU usage (a small fraction of a percent), and about 4kb of bandwidth saved per session (TLS has no appreciable effect on bandwidth after the initial handshake). So, assuming you keep the connection open for an entire game, you're saving practically nothing.

However, having the data sent in the clear makes it easy for someone that's interested in playing around with your game to see what it's doing. Once they know what your protocol is, they can then use that to their advantage. A person using a tool designed to do some task is always going to outperform someone that does not have that tool. Just casually thinking, I've come up with botting, high score manipulation, false client updates, tool assisted plays, and session hijacking.

Botting, for example, is having the computer play for you. Computers are really good at looking ahead a million moves in advance, so they can almost always select the correct, infallible move to make in any circumstance faster than a human. This means they'll win, and real players will lose, which ultimately means your game will end up being abandoned or just full of bots playing each other.

High scores mean things to people. It's an ego thing. So, when they play and get a score of 250, and see that the top player has a score of 4,294,967,295, they're not going to bother playing. For example, this might happen if the high score code has an easy-to-break protocol (yes, some games actually just report a high score, and the server just accepts it). That part should be protected from tampering.

False client updates may or may not be a problem, but basically it comes down to if you can "lie" to a client to make it think the game is in a different state than it actually is. For example, people might appear at the wrong place on a map, people can teleport "magically" because the server accepts the coordinates without validating input, etc. You can do this even with encryption, but that means you've had to modify the binary instead of just writing your own client.

Tool assisted plays are similar to botting: the person's still playing, but they're guided by the tool to make optimal decisions, in real time, even if they're losing. A person with a tool will usually perform better than one without (assuming some practice, of course), so this is again usually considered cheating, and impossible to detect short of a watch dog to protect the client. It's even easier if you can modify the packets any way you desire.

Session hijacking could occur if they can figure out the part of the connection that represents their session. You see, you can't just downgrade a TLS connection back to a non-encrypted state (at least, not that I can tell). So, that means you have to drop the connection and open a new one. This new connection needs to identify to the server who it is. Sure, you can use some sort of token, but it'd better be a nonce (a single use value), otherwise the attacker will know the session information, and could possibly trick the legitimate client from continuing, perhaps by replaying the connection to the server, etc.

All in all, you should always use TLS. Even if it's a game of Tic-Tac-Toe or Connect Four. Someone, somewhere, will want to cheat at your game, and you can basically prevent entire classes of cheating simply by enabling a secure channel. Except for a very minor startup cost, encryption is essentially free, so not using it has no real benefits. If you're authenticating securely, it makes no sense to switch to a non-secure channel later, since you've already paid the price of startup.

  • Wow! Thanks for the amazingly long reply! So TLS makes it so you can't read the packets in Chrome and easily write clients to send packets as well? There's no way for clients to just read the packets before they get encrypted?
    – Chron Bag
    Jun 12, 2016 at 8:23
  • @ChronBag No, if the user goes in to the browser's developer console, they can still see what's going on. However, they lose the ability to use external tools like Wireshark. Also, you would consider minifying your code (e.g. Closure) so that it is more challenging to debug the application. There's really not a 100% foolproof way to prevent cheaters, but you can certainly make it so it's not worth their effort.
    – phyrfox
    Jun 12, 2016 at 8:57
  • Yeah my code is already minified. So maybe I don't quite understand but it seems like the gist of your answer is that using TLS will prevent people from inspecting the packets but you can just do that with the developer console. I guess I'll use it anyway because I assume I'm ignorant with regard to its true importance and its apparently cheap.
    – Chron Bag
    Jun 12, 2016 at 9:09
  • @ChronBag Using encryption will primarily help avoid the class of cheats available where player A can affect player B, but it also limits a user's choice of tools that they can use to try and break your game, such as building a proxy server, or capturing all that network data in a file they can easily read later (the developer console isn't designed for these tasks). You'd need to go to a native application for even better security, but encryption is cheap enough that it's worth using all the time.
    – phyrfox
    Jun 12, 2016 at 9:23
  • 1
    It's not too difficult to write a generic browser extension that intercepts all network calls in the browser and passes it to Wireshark or other cheating tools before proxying it, possibly after modifications, to your game server. Encryption can't protect against that class of cheats.
    – Lie Ryan
    Jun 12, 2016 at 9:44

You should use secure WebSockets protocol in your product.

Given (extremely little) information you provided about the details of your game*. Only general answer is possible to the question**:

What is the worst thing that could happen if I don't enable wss?

If you design and build a system disregarding common security precautions:

  • at best nothing will happen;

  • then there is a whole grey area where you might either end up losing an opportunity, or have to allocate excessive resources to make up for the initial decision;

  • at worse - there is no limit to bad things that may happen.

* It is impossible to evaluate the impact of using unencrypted communication not knowing in full detail what the game is. Particularly: How are you capitalising on game? Are users playing against each other? Are users incentivised to cheat (either materially or in form of score tables)? The information required for such an analysis should also include future development of the game, for example what to do if it catches on and you change the model from free and decide to capitalise in future.

** An audit of all possible dangers for using unencrypted communication in a product must take into account so many factors that it would quickly exceed the costs of implementing proper encryption techniques.

  • I know I'm ignorant that's why I'm asking. The thing is, I can't think of anything that can go wrong. The game is casual. There's no money involved but if there was, it would go over https, not websockets.
    – Chron Bag
    Jun 12, 2016 at 6:46

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .