Skip to main content
Ces bonnes pratiques sont fournies à titre de références exemplaires. Évaluez vos implémentations de manière indépendante.
Les bonnes pratiques dépendent du type de connexion (pair à pair ou client/serveur).

​
Pair à pair

Utilisez PlayFab Party. Il gère de manière transparente le chiffrement et l’authentification pour la communication pair à pair et est fortement recommandé pour tout le trafic pair à pair dans les titres GDK. Disponible sur plusieurs plateformes avec prise en charge inter-réseaux. Consultez PlayFab Party.

​
Client/serveur

Utilisez MsQuic. QUIC offre une sécurité et un chiffrement intégrés. Des versions GDK de la bibliothèque sont disponibles parallèlement aux builds client/serveur Windows et Linux. MsQuic chiffre la connexion et authentifie le serveur via des certificats TLS standard ; utilisez néanmoins l’authentification par jeton XSTS pour authentifier le client auprès du serveur.

​
Client/serveur personnalisé

Si vous devez développer votre propre solution, utilisez DTLS avec une authentification du serveur par certificat TLS et une authentification du client par jeton XSTS. L’implémentation de DTLS via l’API Bcrypt du GDK est complexe et sujette aux bogues de protocole. Préférez OpenSSL : activement maintenu, multiplateforme et largement examiné. Livrez la dernière version mineure d’OpenSSL publiquement disponible au moment de la sortie du titre, et mettez-la à jour après la sortie en cas de divulgations de sécurité affectant les fonctionnalités que vous utilisez. Les dérivés d’OpenSSL ou les bibliothèques non open source ne sont pas maintenus/examinés au même niveau : évitez-les. Configuration DTLS OpenSSL minimale : option de chiffrement HIGH (suites de chiffrement « high » uniquement). Pour une sécurité optimale, limitez-vous aux suites de chiffrement qui incluent tous les éléments suivants :
  • AES256
  • GCM
  • SHA256 ou supérieur
Les listes de chiffrement OpenSSL standard contiennent encore des suites faibles qui peuvent être attaquées. AES256-GCM est accéléré matériellement sur XBOX et les processeurs modernes.

​
Authentification du serveur

Authentifiez les serveurs via DTLS à l’aide de certificats SSL ancrés dans une autorité de certification reconnue par le GDK et la plateforme. Consultez Microsoft Trusted Root Participants. Utilisez un certificat générique sur l’ensemble des serveurs, par exemple *.servers.mytitle.com couvrant des noms tels que na-1230.servers.mytitle.com. Cela permet d’utiliser des certificats préinstallés pour des instances allouées dynamiquement. MsQuic utilise le même chemin d’authentification que les requêtes web HTTPS et expose des API de configuration pour le certificat de serveur ancré. Consultez l’authentification du serveur dans MsQuic.

​
Authentification du client

Les clients doivent également s’authentifier via DTLS à l’aide de certificats ancrés dans une autorité de certification.
N’incluez pas de certificat client dans le package du titre. Il ne peut pas être lié à un utilisateur ou à une instance client spécifique, et ne peut donc pas authentifier de manière sécurisée.
Émettez plutôt les certificats clients de manière sécurisée au moment de l’exécution et validez-les via un service de titre authentifié avec XSTS. Deux types de requêtes suffisent : 1. Émettre un certificat client Utilise les informations du jeton XSTS pour émettre un nouveau certificat feuille signé par l’autorité de certification client du titre (clients.mytitle.com). Faites correspondre le délai d’expiration à celui du jeton XSTS (généralement 4 heures). Le nom du certificat inclut un nonce aléatoire sécurisé (par exemple l8n4ulxga3.clients.mytitle.com), jamais de PII / XUID / consoleID (le nonce est visible dans la négociation DTLS). Le service stocke dans sa base de données interne : le nom du certificat, le hachage, l’expiration, le XUID du joueur associé et le type d’appareil. Supprimez les entrées expirées.
Réponse en cas de réussite :
Le client suit l’expiration et utilise le certificat pour toutes les connexions DTLS ; il le renouvelle au plus tard à l’expiration. 2. Valider le ou les certificats clients Point de terminaison réservé aux serveurs (non accessible publiquement). Reçoit des paires de certificat et de XUID attendu, et renvoie valide ou non valide en fonction de la base de données interne. Les entrées expirées sont non valides. Le type d’appareil restreint davantage la validité (bloque la communication entre appareils différents).
Corps de la requête :
Réponse :
Le serveur ne poursuit que si le certificat est valide. Mettez en cache les certificats validés sur le serveur jusqu’à leur expiration. Pour plus d’efficacité, intégrez la validation aux flux de matchmaking / d’allocation de serveurs : le service d’allocation peut renvoyer le nonce ou le hachage de certificat attendu ainsi que les XUID attendus pour une nouvelle session. Consultez l’authentification du client dans MsQuic. Ce flux fonctionne également en pair à pair, mais exige une grande prudence pour empêcher les attaques par certificat dupliqué ou par sondage d’identité. Par souci de simplicité, préférez PlayFab Party pour le pair à pair sécurisé.

​
Numéros de séquence des messages

Incluez les numéros de séquence dans la charge utile chiffrée afin que les attaquants ne puissent pas les observer ni les modifier pour supprimer, dupliquer ou réordonner des paquets. Les numéros ne doivent pas être prévisibles :
  • Initialisez-les avec une valeur de départ aléatoire sécurisée et augmentez-les de façon monotone.
  • N’utilisez pas rand() ni de fonctions de hachage : elles ne sont pas sécurisées sur le plan cryptographique.
  • Utilisez BCryptGenRandom pour la valeur initiale.
MsQuic chiffre automatiquement l’intégralité de la charge utile de données, y compris les numéros de séquence personnalisés.

​
Qualité de service (QoS) client/serveur

Les sondes UDP de QoS sélectionnent le meilleur centre de données/serveur. Elles sont généralement indépendantes de l’identité de l’utilisateur et peuvent s’exécuter avant la connexion ; l’authentification et le chiffrement complets ne sont donc pas disponibles. Pour atténuer les risques :
  • N’incluez jamais de données utilisateur, client ou serveur dans la charge utile de QoS. Considérez les sondes comme accessibles publiquement : randomisez ou mettez à zéro la charge utile.
  • N’analysez pas les données de la charge utile. Les attaquants modifient les charges utiles pour exploiter des bogues d’analyse. Ne répondez qu’en fonction des informations d’en-tête des paquets.
  • Testez et renforcez l’implémentation de l’analyse QoS : gardez-la aussi simple que possible. Effectuez des tests de fuzzing.
Gérez la QoS sur des serveurs QoS dédiés, et non sur les serveurs de jeu du titre, afin d’isoler l’impact (y compris celui des attaques DDoS).

​
Documentation d’API associée

​
Voir aussi

Last modified on October 6, 2026