Skip to main content
Estas práticas recomendadas são fornecidas como referências exemplares. Avalie suas implementações de forma independente.
As práticas recomendadas dependem do tipo de conexão (ponto a ponto ou cliente/servidor).

​
Ponto a ponto

Use o PlayFab Party. Ele lida de forma transparente com a criptografia e a autenticação da comunicação ponto a ponto e é altamente recomendado para todo o tráfego ponto a ponto em títulos GDK. Disponível em várias plataformas com suporte entre redes. Consulte PlayFab Party.

​
Cliente/servidor

Use o MsQuic. O QUIC oferece segurança e criptografia integradas. Versões GDK da biblioteca estão disponíveis junto com builds de cliente/servidor para Windows e Linux. O MsQuic criptografa a conexão e autentica o servidor por meio de certificados TLS padrão; ainda assim, use a autenticação por token XSTS para autenticar o cliente no servidor.

​
Cliente/servidor personalizado

Se você precisar criar sua própria solução, use DTLS com autenticação do servidor por certificado TLS e autenticação do cliente por token XSTS. Implementar DTLS por meio da API Bcrypt do GDK é complexo e propenso a bugs de protocolo. Prefira o OpenSSL: mantido ativamente, multiplataforma e amplamente revisado. Inclua a versão secundária mais recente do OpenSSL disponível publicamente no lançamento do título e atualize-a após o lançamento em caso de divulgações de segurança que afetem a funcionalidade que você usa. Derivados do OpenSSL ou bibliotecas que não são de código aberto não são mantidos/revisados no mesmo nível; evite-os. Configuração mínima de DTLS do OpenSSL: opção de cifra HIGH (somente conjuntos de cifras “high”). Para obter a melhor segurança, restrinja aos conjuntos de cifras que incluam todos os itens a seguir:
  • AES256
  • GCM
  • SHA256 ou superior
As listas de cifras padrão do OpenSSL ainda contêm conjuntos fracos que podem ser atacados. O AES256-GCM tem aceleração de hardware no XBOX e em CPUs modernas.

​
Autenticação do servidor

Autentique os servidores via DTLS usando certificados SSL com raiz em uma AC reconhecida pelo GDK e pela plataforma. Consulte Microsoft Trusted Root Participants. Use um certificado curinga entre os servidores, por exemplo *.servers.mytitle.com, abrangendo nomes como na-1230.servers.mytitle.com. Isso permite certificados pré-instalados para instâncias alocadas dinamicamente. O MsQuic usa o mesmo caminho de autenticação das solicitações da Web HTTPS e expõe APIs de configuração para o certificado de servidor com raiz. Consulte autenticação do servidor no MsQuic.

​
Autenticação do cliente

Os clientes também devem se autenticar via DTLS usando certificados com raiz em uma AC.
Não inclua um certificado de cliente no pacote do título. Ele não pode ser vinculado a um usuário ou instância de cliente específica e, portanto, não pode autenticar com segurança.
Em vez disso, emita certificados de cliente com segurança em tempo de execução e valide-os por meio de um serviço do título autenticado com XSTS. Dois tipos de solicitação são suficientes: 1. Emitir certificado de cliente Usa as informações do token XSTS para emitir um novo certificado folha assinado pela AC de clientes do título (clients.mytitle.com). Faça o tempo de expiração corresponder ao do token XSTS (normalmente 4 horas). O nome do certificado inclui um nonce aleatório seguro (por exemplo, l8n4ulxga3.clients.mytitle.com), nunca PII / XUID / consoleID (o nonce fica visível no handshake DTLS). O serviço armazena em seu banco de dados interno: nome do certificado, hash, expiração, XUID do jogador associado e tipo de dispositivo. Remova as entradas após a expiração.
Resposta de sucesso:
O cliente acompanha a expiração e usa o certificado para todas as conexões DTLS; renova-o no momento da expiração ou antes. 2. Validar certificado(s) de cliente Ponto de extremidade exclusivo para servidores (não acessível publicamente). Recebe pares de certificado e XUID esperado e retorna válido ou inválido com base no banco de dados interno. Entradas expiradas são inválidas. O tipo de dispositivo restringe ainda mais a validade (bloqueia a comunicação entre dispositivos diferentes).
Corpo da solicitação:
Resposta:
O servidor só prossegue se for válido. Armazene em cache no servidor os certificados validados até a expiração. Para maior eficiência, incorpore a validação aos fluxos de matchmaking / alocação de servidores: o serviço de alocação pode retornar o nonce ou hash do certificado esperado e os XUIDs esperados para uma nova sessão. Consulte autenticação do cliente no MsQuic. Esse fluxo também funciona para ponto a ponto, mas exige muito cuidado para evitar ataques de certificado duplicado ou de sondagem de identidade. Para simplificar, prefira o PlayFab Party para comunicação ponto a ponto segura.

​
Números de sequência de mensagens

Inclua números de sequência dentro do payload criptografado para que os invasores não possam observá-los ou modificá-los para descartar, duplicar ou reordenar pacotes. Os números não devem ser previsíveis:
  • Inicialize com um valor inicial aleatório seguro e incremente de forma monotônica.
  • Não use rand() nem funções de hash, pois não são criptograficamente seguras.
  • Use BCryptGenRandom para a semente.
O MsQuic criptografa automaticamente todo o payload de dados, incluindo números de sequência personalizados.

​
Qualidade de Serviço (QoS) cliente/servidor

As sondagens UDP de QoS selecionam o melhor datacenter/servidor. Normalmente, elas são independentes da identidade do usuário e podem ser executadas antes da entrada, portanto a autenticação e a criptografia completas não estão disponíveis. Mitigue:
  • Nunca inclua dados do usuário, do cliente ou do servidor no payload de QoS. Trate as sondagens como publicamente acessíveis: torne o payload aleatório ou preencha-o com zeros.
  • Não analise os dados do payload. Os invasores modificam os payloads para explorar bugs de analisador. Responda apenas com base nas informações do cabeçalho do pacote.
  • Teste e reforce a implementação de análise de QoS, mantendo-a o mais simples possível. Faça testes de fuzzing nela.
Lide com o QoS em servidores de QoS dedicados, não nos servidores de jogo do título, para isolar o impacto (incluindo DDoS).

​
Documentação de API relacionada

​
Confira também

Last modified on October 6, 2026