Dois-je utiliser des websockets (ws) ou des websockets sécurisés (wss) pour mon jeu?
Je fais un jeu et j'utilise des websockets pour 99% de la communication. Le seul http (s) est au chargement initial de la page et lors de la connexion/inscription.
Je suis un noob complet, corrigez-moi si je me trompe, mais SSL sert uniquement à empêcher l'homme au milieu des attaques, non? Aucun des paquets que j'envoie via des sockets Web n'est "confidentiel". C'est surtout juste [packetName, xCoord, yCoord]. Je ne peux penser à aucun des paquets de jeu que j'envoie où il importerait qu'un tiers les attrape (même si cette personne était également dans le même jeu dans la même pièce parce que tout le monde peut toujours voir tout le monde pendant le jeu).
Je sais que c'est généralement considéré comme la meilleure pratique de toujours utiliser SSL, mais mon jeu a une tonne de communication entre les clients et le serveur (beaucoup de mises à jour de position par seconde et je veux aussi peu de retard/bande passante/traitement que possible), donc je Je me demande si c'est nécessaire?
Quelle est la pire chose qui puisse arriver si je n'active pas wss?
(tl; dr en bas)
Le chiffrement est essentiellement gratuit à ce stade, même sur les connexions d'accès à distance. Presque toutes les langues principales l'ont intégré ou ont une bibliothèque pour cela, etc. L'avantage de ne pas utiliser TLS/SSL est une très petite fraction de seconde de temps de démarrage, une réduction très négligeable de l'utilisation du processeur (une petite fraction de pour cent), et environ 4 Ko de bande passante économisée par session (TLS n'a pas d'effet appréciable sur la bande passante après la prise de contact initiale). Donc, en supposant que vous gardez la connexion ouverte pour un jeu entier, vous n'économisez pratiquement rien.
Cependant, le fait d'envoyer les données en clair permet à une personne intéressée de jouer avec votre jeu de voir ce qu'elle fait. Une fois qu'ils connaissent votre protocole, ils peuvent l'utiliser à leur avantage. Une personne utilisant un outil conçu pour effectuer une tâche va toujours surpasser une personne qui ne dispose pas de cet outil. En pensant à la désinvolture, j'ai trouvé l'embouteillage, la manipulation des meilleurs scores, les fausses mises à jour des clients, les jeux assistés par outils et le détournement de session.
Botting, par exemple, fait jouer l'ordinateur pour vous. Les ordinateurs sont vraiment bons pour anticiper un million de mouvements à l'avance, de sorte qu'ils peuvent presque toujours sélectionner le mouvement correct et infaillible à effectuer en toute circonstance plus rapidement qu'un humain. Cela signifie qu'ils gagneront et que les vrais joueurs perdront, ce qui signifie en fin de compte que votre jeu finira par être abandonné ou simplement plein de robots jouant les uns contre les autres.
Des scores élevés signifient des choses pour les gens. C'est une affaire d'ego. Donc, quand ils jouent et obtiennent un score de 250, et voient que le meilleur joueur a un score de 4 294 967 295, ils ne vont pas s'embêter à jouer. Par exemple, cela peut se produire si le code de score élevé a un protocole facile à casser (oui, certains jeux signalent simplement un score élevé et le serveur l'accepte simplement). Cette partie doit être protégée contre toute altération.
Les fausses mises à jour des clients peuvent ou non être un problème, mais en gros, cela revient à si vous pouvez "mentir" à un client pour lui faire croire que le jeu est dans un état différent de ce qu'il est réellement. Par exemple, les gens peuvent apparaître au mauvais endroit sur une carte, les gens peuvent se téléporter "comme par magie" parce que le serveur accepte les coordonnées sans valider la saisie, etc. Vous pouvez le faire même avec le cryptage, mais cela signifie que vous avez dû modifier le binaire au lieu d'écrire simplement votre propre client.
Les jeux assistés par outil sont similaires à la mise en bouteille: la personne joue toujours, mais elle est guidée par l'outil pour prendre des décisions optimales, en temps réel, même si elle perd. Une personne avec un outil réussira généralement mieux qu'une sans (en supposant une certaine pratique, bien sûr), donc cela est généralement considéré comme de la triche et impossible à détecter à court d'un chien de garde pour protéger le client. C'est encore plus facile si vous pouvez modifier les paquets comme vous le souhaitez.
Le détournement de session peut se produire s’ils peuvent déterminer la partie de la connexion qui représente leur session. Vous voyez, vous ne pouvez pas simplement rétrograder une connexion TLS à un état non crypté (du moins, pas que je sache). Donc, cela signifie que vous devez interrompre la connexion et en ouvrir une nouvelle. Cette nouvelle connexion doit identifier le serveur qui il s'agit. Bien sûr, vous pouvez utiliser une sorte de jeton, mais ce serait mieux un nonce (une valeur à usage unique), sinon l'attaquant connaîtra les informations de session, et pourrait éventuellement tromper le client légitime de continuer, peut-être en rejouant la connexion à le serveur, etc.
Dans l'ensemble, vous devez toujours utiliser TLS. Même si c'est un jeu de Tic-Tac-Toe ou Connect Four. Quelqu'un, quelque part, voudra tricher à votre jeu, et vous pouvez essentiellement empêcher des classes entières de tricherie simplement en activant un canal sécurisé. À l'exception d'un coût de démarrage très mineur, le chiffrement est essentiellement gratuit, donc ne pas l'utiliser ne présente aucun avantage réel. Si vous vous authentifiez en toute sécurité, cela n'a aucun sens de passer à un canal non sécurisé plus tard, car vous avez déjà payé le prix du démarrage.
Vous devez utiliser le protocole WebSockets sécurisé dans votre produit.
Compte tenu (extrêmement peu) des informations que vous avez fournies sur les détails de votre jeu*. Seule une réponse générale est possible à la question**:
Quelle est la pire chose qui puisse arriver si je n'active pas wss?
Si vous concevez et construisez un système sans tenir compte des précautions de sécurité courantes:
au mieux, rien ne se passera;
il y a ensuite toute une zone grise où vous pourriez soit perdre une opportunité, soit devoir allouer des ressources excessives pour compenser la décision initiale;
au pire - il n'y a pas de limite aux mauvaises choses qui peuvent arriver.
* Il est impossible d'évaluer l'impact de l'utilisation d'une communication non cryptée sans savoir en détail ce qu'est le jeu. En particulier: Comment capitalisez-vous sur le jeu? Les utilisateurs jouent-ils les uns contre les autres? Les utilisateurs sont-ils incités à tricher (matériellement ou sous forme de tableaux de score)? Les informations requises pour une telle analyse devraient également inclure le développement futur du jeu, par exemple ce qu'il faut faire s'il se propage et que vous modifiez le modèle gratuitement et décidez de capitaliser à l'avenir.
** Un audit de tous les dangers possibles liés à l'utilisation de communications non cryptées dans un produit doit prendre en compte autant de facteurs qu'il dépasserait rapidement les coûts de mise en œuvre de techniques de cryptage appropriées.