Como o DPI Detecta Proxies MTProto: Uma Análise Técnica da Detecção de Protocolos por Assinaturas
O artigo explora como o DPI (Deep Packet Inspection) evoluiu para detectar proxies MTProto, analisando o comportamento do tráfego em vez de apenas o handshake TLS. Ele detalha as técnicas de análise estatística, como tamanho de pacotes, tempos e correlação de IP, e discute a batalha contínua entre detecção e ofuscação.
MundiX News·31 de maio de 2026·10 min de leitura·👁 22 views
Como o DPI Detecta Proxies MTProto: Uma Análise Técnica da Detecção de Protocolos por Assinaturas
No final de maio de 2026, a internet russa foi atingida por uma onda de relatos de falhas em proxies MTProto. Os serviços que os usuários usavam para contornar a lentidão do Telegram pararam de funcionar quase simultaneamente para quase todos os provedores. O "Código Durov" registrou, em sua formulação, um número sem precedentes de reclamações. Canais técnicos foram preenchidos com manchetes como "O RKN aprimorou os bloqueios, é impossível contornar".
Eu quero analisar isso não como uma notícia, mas do ponto de vista da engenharia: o que tecnicamente está por trás da frase "DPI aprendeu a analisar assinaturas de protocolo", por que o mecanismo Fake-TLS, que funcionou por anos, de repente parou de salvar, e quais propriedades fundamentais do tráfego entregam proxies, mesmo quando a carga útil é criptografada.
Imediatamente, vou definir o gênero. Esta é uma análise da teoria da detecção de protocolos - uma área na interseção da análise de rede, estatística e DPI. Esta não é uma instrução sobre como contornar os bloqueios: não haverá receitas específicas de "como fazer para que funcione" aqui, existem recursos especializados para isso. O objetivo é entender como a detecção é tecnicamente organizada, porque esta é uma tarefa de engenharia interessante em si, e a compreensão da mecânica é útil para qualquer pessoa que trabalhe com redes.
Breve Introdução: O que é MTProto e Fake-TLS
Para que a conversa seja específica, é necessária uma base.
MTProto é o protocolo de transporte proprietário do Telegram. Ele foi criado não apenas para criptografia, mas também para trabalhar em condições de filtragem de tráfego. Dentro do Telegram, há um mecanismo de proxy embutido - MTProxy, que funciona diretamente no cliente, sem software adicional.
A principal característica do MTProxy nos últimos anos é o Fake-TLS (também conhecido como FakeTLS, TLS preenchido). A ideia é mascarar a conexão como HTTPS normal. Quando você abre qualquer site via HTTPS, ocorre um TLS handshake entre o cliente e o servidor - troca de mensagens ClientHello, ServerHello, troca de chaves. Fake-TLS envolve o tráfego MTProto para que o início da conexão se pareça com um handshake TLS 1.3 legítimo para algum domínio normal.
Para o DPI, que só olha para o início da conexão, isso parecia uma visita normal a um site. Portanto, por anos, o Fake-TLS MTProxy passou calmamente pelos filtros - o sistema não conseguia distingui-lo da navegação na web comum, sem quebrar todo o HTTPS ao mesmo tempo.
Isso funcionou. Até um certo ponto.
Etapa 1: Detecção por TLS Handshake (o que era antes)
O primeiro nível de detecção, que foi aplicado no início de 2026, é a análise do próprio TLS handshake. E aqui há uma sutileza que é importante entender.
Fake-TLS imita TLS, mas não imita perfeitamente. A pilha TLS real do navegador (BoringSSL no Chrome, NSS no Firefox) forma o ClientHello com um determinado conjunto de campos em uma determinada ordem: lista de cipher suites, extensões, curvas elípticas, formatos de ponto, ALPN, algoritmos de assinatura. Esta "impressão digital" recebeu o nome de JA3 (e seu desenvolvimento JA4) - um hash dos parâmetros ClientHello, pelo qual você pode identificar a biblioteca do cliente.
A implementação do Fake-TLS no MTProxy esta impressão digital difere do navegador real. Não muito, mas mensurável. Em algum lugar, uma ordem diferente de extensões, em algum lugar, a extensão que o Chrome real tem está ausente, em algum lugar, o conjunto de cipher suites não corresponde à versão atual do navegador.
O DPI com uma base de impressões digitais JA3/JA4 de navegadores populares pode comparar: aqui veio um ClientHello que se declara como Chrome, mas seu hash JA3 não corresponde a nenhuma versão real do Chrome. Suspeito - marcamos.
Foi exatamente isso que aconteceu em março-abril de 2026. O TSPU recebeu regras atualizadas que pegaram a incompatibilidade da impressão digital TLS. Os desenvolvedores de proxy responderam ajustando a impressão digital para navegadores atuais - a clássica corrida de escudo e espada.
Mas a detecção por handshake tem uma limitação fundamental:
a impressão digital pode ser falsificada. Se você souber qual JA3 é o Chrome mais recente, poderá formar um ClientHello com exatamente o mesmo. Esta é uma questão de esforço de engenharia, não de possibilidade fundamental. Portanto, o regulador passou para o próximo nível - onde a falsificação é muito mais difícil.
Etapa 2: Análise Estatística de Assinaturas de Protocolo
É aqui que começa o mais interessante do ponto de vista técnico. A nova rodada, sobre a qual foi escrito no final de maio de 2026, é a análise não do handshake, mas do comportamento do tráfego ao longo da conexão.
A ideia principal: mesmo que o início da conexão seja perfeitamente mascarado como TLS, a troca de dados subsequente está sujeita à lógica de outro protocolo - MTProto. E cada protocolo tem invariantes estatísticos que são difíceis de ocultar sem quebrar o próprio protocolo.
O que é analisado especificamente.
Tamanhos de Pacotes e sua Distribuição
O tráfego HTTPS real ao carregar uma página da web tem um padrão característico: um grande pico no início (HTML, CSS, JS, imagens voam em TLS-records grandes próximos ao MTU), depois uma calmaria, depois pequenas solicitações à medida que você interage. A distribuição dos tamanhos de pacotes de uma sessão da web é um perfil "irregular" com fases distintas.
MTProto no modo mensageiro se comporta de forma diferente. Este é um fluxo de pequenas mensagens - texto, status de digitação, pings, confirmações de entrega. A distribuição dos tamanhos de pacotes é diferente: muitos pacotes pequenos de tamanho semelhante, um fluxo suave sem picos característicos da web. Mesmo envolvido em uma camada TLS, esse padrão é estatisticamente diferente da visualização real de sites.
O DPI pode construir um histograma dos tamanhos de pacotes em uma conexão e compará-lo com perfis de referência. Uma sessão da web e uma sessão MTProxy dão histogramas diferentes.
Tempos e Direção do Tráfego
O segundo sinal é a estrutura temporal. O carregamento da web é assimétrico: o cliente envia uma pequena solicitação, o servidor responde com um grande volume de dados. A relação upload/download para navegação na web é fortemente tendenciosa para download.
O tráfego de mensagens é mais simétrico: você envia e recebe mensagens de tamanho comparável. Além disso, há um padrão "de longa duração" característico - a conexão permanece aberta por horas com pings keep-alive periódicos em intervalos regulares. As conexões da web não se comportam assim - são de curta duração, abertas-fechadas.
A regularidade dos pings é um marcador forte separado. Se um pacote de tamanho fixo passa a cada N segundos em uma "conexão TLS" - isso é muito semelhante a um keep-alive de um mensageiro, e não a uma web.
Entropia e Estrutura da Carga Útil
O terceiro nível é a análise da entropia do fluxo criptografado. Aqui é sutil: tanto TLS quanto MTProto criptografam dados, então a carga útil em ambos os casos se parece com "ruído" de alta entropia. Mas existem nuances na forma como os TLS-records são estruturados em cima da criptografia: seus comprimentos, cabeçalhos, padrão de fragmentação. MTProto em cima do Fake-TLS forma records não exatamente como uma pilha TLS real ao transferir tráfego HTTP/2.
Correlação Comportamental por IP
E, finalmente, um marcador sobre o qual foi escrito diretamente nas notícias: correlação de conexões ao mesmo IP. A lógica é a seguinte. Um MTProxy público atende muitos usuários. Todos eles se conectam ao mesmo endereço IP. Se o Fake-TLS para todos eles imita a mesma versão do navegador (porque o servidor proxy usa a mesma impressão digital), o DPI vê uma imagem estranha: dezenas e centenas de clientes chegam ao mesmo IP, e todos com uma impressão digital TLS idêntica da mesma, muitas vezes desatualizada, versão do navegador.
No mundo real, isso não acontece. Os usuários se conectam ao mesmo site com navegadores diferentes, versões diferentes, sistemas operacionais diferentes - uma dispersão natural da impressão digital. E quando cem clientes chegam com um ClientHello byte a byte idêntico "Chrome da versão de seis meses atrás" - esta é uma anomalia estatística que aponta diretamente para um proxy.
Por que isso funciona e é mais difícil de falsificar do que um handshake
Aqui está o ponto de engenharia fundamental, pelo qual comecei a análise.
Falsificar uma impressão digital estática (JA3 handshake) é relativamente simples: copiou os parâmetros de um navegador real, formou o mesmo ClientHello. Configurado uma vez - funciona até que o navegador seja atualizado.
Falsificar estatísticas dinâmicas de protocolo é fundamentalmente mais difícil. Porque essas estatísticas são geradas pela própria lógica de funcionamento do MTProto. Para que o perfil dos tamanhos de pacotes e tempos seja indistinguível da web, você precisa:
gerar tráfego "semelhante à web" falso em cima do real - esta é uma sobrecarga enorme que mata o desempenho e ainda não é perfeita;
reescrever a própria maneira de empacotar dados para que corresponda estatisticamente ao HTTP/2 real sobre TLS - isso, na verdade, é "reprocessar o protocolo", sobre o qual foi escrito nas notícias. É por isso que a frase "é impossível evitar, o Telegram deve reprocessar os protocolos" na notícia original não é totalmente clickbait. Há uma parte da verdade nisso: a correção cosmética da impressão digital não pode escapar da detecção estatística, você precisa mudar a forma como o protocolo forma o tráfego no nível dos padrões.
Embora "impossível" seja um exagero. É possível. É só que isso requer mudanças mais profundas do que a substituição de um hash. E esta é novamente uma corrida, apenas em um novo nível.
Contexto: Por que isso faz parte de uma grande corrida
Vale a pena entender que a detecção de MTProxy é apenas uma frente. De dezembro de 2025 a maio de 2026, a julgar pelas publicações, os sistemas DPI aprenderam a reconhecer outros protocolos de contorno por assinaturas: WireGuard, OpenVPN, VLESS, SOCKS5, L2TP. A lógica é a mesma em todos os lugares - cada protocolo tem uma impressão digital estatística, e com poder computacional suficiente, ela pode ser destacada.
A resposta dos instrumentos de contorno também segue um vetor claro - ofuscação, que não tem uma assinatura estável. Protocolos como AmneziaWG (WireGuard ofuscado) adicionam ruído aleatório ao tráfego, randomizam os tamanhos e tempos dos pacotes para que a conexão não tenha um perfil estatístico estável. Este é um contra-ataque direto contra a detecção estatística: se o perfil for diferente cada vez, é difícil construir uma referência para comparação.
Esta é a dinâmica clássica da resistência à censura: os detectores procuram invariantes, as ferramentas de contorno as eliminam, os detectores procuram novas. Academicamente, isso é bem descrito em trabalhos sobre detecção e ofuscação de protocolos - por exemplo, estudos do grupo Tor sobre transportes plugáveis, trabalhos sobre a detecção de Shadowsocks pelo GFW chinês.
Limitação do lado do hardware
Há outro lado, sem o qual o quadro está incompleto - o custo da detecção.
A análise do TLS handshake é barata: olhou para os primeiros poucos pacotes da conexão, calculou o hash, comparou com a base. Isso pode ser feito em tempo real para todo o tráfego.
A análise estatística do comportamento é mais cara.
Para construir um histograma dos tamanhos de pacotes e um perfil de tempos, você precisa rastrear a conexão ao longo do tempo, acumular estado, calcular estatísticas. Isso requer memória para cada conexão e cálculos. Com milhões de conexões simultâneas, a carga no equipamento aumenta exponencialmente.
Em abril de 2026, houve um episódio revelador: ao tentar sobrecarregar o TSPU com um grande número de regras de filtragem (de acordo com publicações, cerca de 40 mil contra os habituais 10-15 mil), o sistema em parte dos nós entrou em bypass - ou seja, começou a passar tráfego sem filtragem, incluindo recursos previamente bloqueados. Esta é uma consequência direta do fato de que a análise profunda é intensiva em recursos, e a largura de banda total do equipamento é finita.
Resulta em um paradoxo interessante, que os especialistas notaram: quanto mais usuários ativam proxies, maior a carga no sistema de filtragem, pior ele lida com todo o resto. A detecção por estatísticas intensifica esse efeito, porque é mais cara do que uma simples verificação de handshake.
O que é verdade na notícia original e o que é um exagero
Já que a ocasião é uma notícia específica, vou analisar suas formulações do ponto de vista técnico.
"O DPI analisa não apenas o handshake, mas também as assinaturas do protocolo - tamanho dos pacotes, impressão digital"
isso é tecnicamente correto. É a transição da análise de handshake para a análise de estatísticas comportamentais que é a essência da nova rodada.
"Se diferentes clientes se conectam ao mesmo IP com a mesma versão desatualizada do navegador - este é um sinal de um proxy"
correto e lógico. Esta é a mesma correlação comportamental por IP, um marcador forte e barato para calcular.
"É impossível evitar isso agora"
exagero. Mais precisamente, "é impossível evitar a correção cosmética da impressão digital". A detecção estatística é contornada pela ofuscação com randomização, e esses métodos existem (AmneziaWG como exemplo). A corrida continua, e não terminou.
"O Telegram deve reprocessar completamente os protocolos"
parcialmente verdade. Para que o Fake-TLS volte a ser indistinguível, você precisa mudar não a impressão digital, mas a forma como o tráfego é formado - isso é mais profundo do que substituir um hash. Mas "reprocessar completamente" é uma dramatização.
Uma imagem típica para notícias técnicas: os fatos principais são verdadeiros, as conclusões são dramatizadas ao nível de "tudo está perdido".
O que é útil tirar disso
Alguns pensamentos que vão além do caso específico com o Telegram.
A criptografia da carga útil não esconde os metadados do tráfego.
Este é um princípio fundamental. Você pode criptografar perfeitamente o conteúdo, mas os tamanhos dos pacotes, tempos, direção, duração da conexão permanecem visíveis. A análise de tráfego (análise de tráfego) é uma disciplina poderosa separada, e ela funciona em cima de qualquer criptografia. Isso se aplica não apenas ao contorno da censura, mas também, por exemplo, à desanonimização no Tor por tempos e vazamentos em mensageiros criptografados por meio de tamanhos de pacotes.
Uma impressão digital estática é fácil de falsificar, o comportamento dinâmico é difícil.
Este é um princípio geral para qualquer detecção. Uma assinatura que pode ser copiada uma vez é uma proteção fraca. Invariantes comportamentais gerados pela própria lógica do sistema - um sinal muito mais estável. Isso se aplica a anti-fraude, detecção de bots e impressão digital de dispositivos.
Qualquer detecção repousa no custo.
Quanto mais profunda a análise, mais cara ela é computacionalmente. Isso cria um limite fundamental: o sistema pode ser sobrecarregado pelo volume. A proteção e o ataque aqui são sempre também a economia de cálculos, não apenas algoritmos.
A ofuscação contra assinaturas é sobre a eliminação de invariantes.
A melhor maneira de não ser pego por estatísticas é não ter estatísticas estáveis. Randomização de tamanhos, tempos, adição de ruído. Este é um contra-ataque que funciona contra qualquer detector que procure um padrão estável.
Resumo
O que aconteceu em maio de 2026 com o MTProxy é a transição da detecção do nível "como o início da conexão se parece" para o nível "como a conexão se comporta ao longo do tempo". Tecnicamente, este é um passo natural: a análise de handshake é contornada pela falsificação da impressão digital, então o regulador passou para a análise estatística, que é mais difícil de falsificar.
Este não é o "fim do Telegram" e não "é impossível contornar" - esta é uma nova rodada da antiga corrida entre detecção e ofuscação de protocolos. A detecção estatística, por sua vez, é contornada pela randomização do tráfego, e as ferramentas para isso já existem. Paralelamente, todo o sistema repousa no teto do poder computacional - a análise profunda é cara, e esta é uma restrição objetiva.
Do ponto de vista puramente da engenharia, esta é uma bela tarefa na interseção da análise de rede, estatística e teoria da detecção. E a compreensão de sua mecânica é útil muito além do tema dos bloqueios - os mesmos princípios funcionam em análise de tráfego, anti-fraude, detecção de bots e análise de canais criptografados.
Esta é uma análise técnica da mecânica da detecção de protocolos, não uma declaração política e não um guia sobre como contornar os bloqueios. Se você tiver correções na parte técnica - escreva nos comentários.
Fontes e para leitura adicional:
Documentação sobre impressão digital JA3/JA4 (Salesforce, FoxIO)
Pesquisa do Projeto Tor sobre transportes plugáveis e detecção de obfs4
Trabalhos sobre a detecção de Shadowsocks pelo sistema GFW (várias publicações acadêmicas sobre medição de censura)
Especificação MTProto na documentação aberta do Telegram
Tags:
DPI
MTProto
TSPU
traffic analysis
JA3
fingerprinting
segurança de rede
detecção de protocolos
🛡️⚡
Pare de pesquisar. Comece a hackear.
O MundiX é seu copiloto de pentest com IA: comandos exatos, análise de outputs e próximo passo na kill chain — em segundos.
Sem cartão para começar · Planos a partir de R$49/mês
Como o DPI Detecta Proxies MTProto: Uma Análise Técnica da Detecção de Protocolos por Assinaturas
No final de maio de 2026, a internet russa foi atingida por uma onda de relatos de falhas em proxies MTProto. Os serviços que os usuários usavam para contornar a lentidão do Telegram pararam de funcionar quase simultaneamente para quase todos os provedores. O "Código Durov" registrou, em sua formulação, um número sem precedentes de reclamações. Canais técnicos foram preenchidos com manchetes como "O RKN aprimorou os bloqueios, é impossível contornar".
Eu quero analisar isso não como uma notícia, mas do ponto de vista da engenharia: o que tecnicamente está por trás da frase "DPI aprendeu a analisar assinaturas de protocolo", por que o mecanismo Fake-TLS, que funcionou por anos, de repente parou de salvar, e quais propriedades fundamentais do tráfego entregam proxies, mesmo quando a carga útil é criptografada.
Imediatamente, vou definir o gênero. Esta é uma análise da teoria da detecção de protocolos - uma área na interseção da análise de rede, estatística e DPI. Esta não é uma instrução sobre como contornar os bloqueios: não haverá receitas específicas de "como fazer para que funcione" aqui, existem recursos especializados para isso. O objetivo é entender como a detecção é tecnicamente organizada, porque esta é uma tarefa de engenharia interessante em si, e a compreensão da mecânica é útil para qualquer pessoa que trabalhe com redes.
Breve Introdução: O que é MTProto e Fake-TLS
Para que a conversa seja específica, é necessária uma base.
MTProto é o protocolo de transporte proprietário do Telegram. Ele foi criado não apenas para criptografia, mas também para trabalhar em condições de filtragem de tráfego. Dentro do Telegram, há um mecanismo de proxy embutido - MTProxy, que funciona diretamente no cliente, sem software adicional.
A principal característica do MTProxy nos últimos anos é o Fake-TLS (também conhecido como FakeTLS, TLS preenchido). A ideia é mascarar a conexão como HTTPS normal. Quando você abre qualquer site via HTTPS, ocorre um TLS handshake entre o cliente e o servidor - troca de mensagens ClientHello, ServerHello, troca de chaves. Fake-TLS envolve o tráfego MTProto para que o início da conexão se pareça com um handshake TLS 1.3 legítimo para algum domínio normal.
Para o DPI, que só olha para o início da conexão, isso parecia uma visita normal a um site. Portanto, por anos, o Fake-TLS MTProxy passou calmamente pelos filtros - o sistema não conseguia distingui-lo da navegação na web comum, sem quebrar todo o HTTPS ao mesmo tempo.
Isso funcionou. Até um certo ponto.
Etapa 1: Detecção por TLS Handshake (o que era antes)
O primeiro nível de detecção, que foi aplicado no início de 2026, é a análise do próprio TLS handshake. E aqui há uma sutileza que é importante entender.
Fake-TLS imita TLS, mas não imita perfeitamente. A pilha TLS real do navegador (BoringSSL no Chrome, NSS no Firefox) forma o ClientHello com um determinado conjunto de campos em uma determinada ordem: lista de cipher suites, extensões, curvas elípticas, formatos de ponto, ALPN, algoritmos de assinatura. Esta "impressão digital" recebeu o nome de JA3 (e seu desenvolvimento JA4) - um hash dos parâmetros ClientHello, pelo qual você pode identificar a biblioteca do cliente.
A implementação do Fake-TLS no MTProxy esta impressão digital difere do navegador real. Não muito, mas mensurável. Em algum lugar, uma ordem diferente de extensões, em algum lugar, a extensão que o Chrome real tem está ausente, em algum lugar, o conjunto de cipher suites não corresponde à versão atual do navegador.
O DPI com uma base de impressões digitais JA3/JA4 de navegadores populares pode comparar: aqui veio um ClientHello que se declara como Chrome, mas seu hash JA3 não corresponde a nenhuma versão real do Chrome. Suspeito - marcamos.
Foi exatamente isso que aconteceu em março-abril de 2026. O TSPU recebeu regras atualizadas que pegaram a incompatibilidade da impressão digital TLS. Os desenvolvedores de proxy responderam ajustando a impressão digital para navegadores atuais - a clássica corrida de escudo e espada.
Mas a detecção por handshake tem uma limitação fundamental:
a impressão digital pode ser falsificada. Se você souber qual JA3 é o Chrome mais recente, poderá formar um ClientHello com exatamente o mesmo. Esta é uma questão de esforço de engenharia, não de possibilidade fundamental. Portanto, o regulador passou para o próximo nível - onde a falsificação é muito mais difícil.
Etapa 2: Análise Estatística de Assinaturas de Protocolo
É aqui que começa o mais interessante do ponto de vista técnico. A nova rodada, sobre a qual foi escrito no final de maio de 2026, é a análise não do handshake, mas do comportamento do tráfego ao longo da conexão.
A ideia principal: mesmo que o início da conexão seja perfeitamente mascarado como TLS, a troca de dados subsequente está sujeita à lógica de outro protocolo - MTProto. E cada protocolo tem invariantes estatísticos que são difíceis de ocultar sem quebrar o próprio protocolo.
O que é analisado especificamente.
Tamanhos de Pacotes e sua Distribuição
O tráfego HTTPS real ao carregar uma página da web tem um padrão característico: um grande pico no início (HTML, CSS, JS, imagens voam em TLS-records grandes próximos ao MTU), depois uma calmaria, depois pequenas solicitações à medida que você interage. A distribuição dos tamanhos de pacotes de uma sessão da web é um perfil "irregular" com fases distintas.
MTProto no modo mensageiro se comporta de forma diferente. Este é um fluxo de pequenas mensagens - texto, status de digitação, pings, confirmações de entrega. A distribuição dos tamanhos de pacotes é diferente: muitos pacotes pequenos de tamanho semelhante, um fluxo suave sem picos característicos da web. Mesmo envolvido em uma camada TLS, esse padrão é estatisticamente diferente da visualização real de sites.
O DPI pode construir um histograma dos tamanhos de pacotes em uma conexão e compará-lo com perfis de referência. Uma sessão da web e uma sessão MTProxy dão histogramas diferentes.
Tempos e Direção do Tráfego
O segundo sinal é a estrutura temporal. O carregamento da web é assimétrico: o cliente envia uma pequena solicitação, o servidor responde com um grande volume de dados. A relação upload/download para navegação na web é fortemente tendenciosa para download.
O tráfego de mensagens é mais simétrico: você envia e recebe mensagens de tamanho comparável. Além disso, há um padrão "de longa duração" característico - a conexão permanece aberta por horas com pings keep-alive periódicos em intervalos regulares. As conexões da web não se comportam assim - são de curta duração, abertas-fechadas.
A regularidade dos pings é um marcador forte separado. Se um pacote de tamanho fixo passa a cada N segundos em uma "conexão TLS" - isso é muito semelhante a um keep-alive de um mensageiro, e não a uma web.
Entropia e Estrutura da Carga Útil
O terceiro nível é a análise da entropia do fluxo criptografado. Aqui é sutil: tanto TLS quanto MTProto criptografam dados, então a carga útil em ambos os casos se parece com "ruído" de alta entropia. Mas existem nuances na forma como os TLS-records são estruturados em cima da criptografia: seus comprimentos, cabeçalhos, padrão de fragmentação. MTProto em cima do Fake-TLS forma records não exatamente como uma pilha TLS real ao transferir tráfego HTTP/2.
Correlação Comportamental por IP
E, finalmente, um marcador sobre o qual foi escrito diretamente nas notícias: correlação de conexões ao mesmo IP. A lógica é a seguinte. Um MTProxy público atende muitos usuários. Todos eles se conectam ao mesmo endereço IP. Se o Fake-TLS para todos eles imita a mesma versão do navegador (porque o servidor proxy usa a mesma impressão digital), o DPI vê uma imagem estranha: dezenas e centenas de clientes chegam ao mesmo IP, e todos com uma impressão digital TLS idêntica da mesma, muitas vezes desatualizada, versão do navegador.
No mundo real, isso não acontece. Os usuários se conectam ao mesmo site com navegadores diferentes, versões diferentes, sistemas operacionais diferentes - uma dispersão natural da impressão digital. E quando cem clientes chegam com um ClientHello byte a byte idêntico "Chrome da versão de seis meses atrás" - esta é uma anomalia estatística que aponta diretamente para um proxy.
Por que isso funciona e é mais difícil de falsificar do que um handshake
Aqui está o ponto de engenharia fundamental, pelo qual comecei a análise.
Falsificar uma impressão digital estática (JA3 handshake) é relativamente simples: copiou os parâmetros de um navegador real, formou o mesmo ClientHello. Configurado uma vez - funciona até que o navegador seja atualizado.
Falsificar estatísticas dinâmicas de protocolo é fundamentalmente mais difícil. Porque essas estatísticas são geradas pela própria lógica de funcionamento do MTProto. Para que o perfil dos tamanhos de pacotes e tempos seja indistinguível da web, você precisa:
gerar tráfego "semelhante à web" falso em cima do real - esta é uma sobrecarga enorme que mata o desempenho e ainda não é perfeita;
reescrever a própria maneira de empacotar dados para que corresponda estatisticamente ao HTTP/2 real sobre TLS - isso, na verdade, é "reprocessar o protocolo", sobre o qual foi escrito nas notícias. É por isso que a frase "é impossível evitar, o Telegram deve reprocessar os protocolos" na notícia original não é totalmente clickbait. Há uma parte da verdade nisso: a correção cosmética da impressão digital não pode escapar da detecção estatística, você precisa mudar a forma como o protocolo forma o tráfego no nível dos padrões.
Embora "impossível" seja um exagero. É possível. É só que isso requer mudanças mais profundas do que a substituição de um hash. E esta é novamente uma corrida, apenas em um novo nível.
Contexto: Por que isso faz parte de uma grande corrida
Vale a pena entender que a detecção de MTProxy é apenas uma frente. De dezembro de 2025 a maio de 2026, a julgar pelas publicações, os sistemas DPI aprenderam a reconhecer outros protocolos de contorno por assinaturas: WireGuard, OpenVPN, VLESS, SOCKS5, L2TP. A lógica é a mesma em todos os lugares - cada protocolo tem uma impressão digital estatística, e com poder computacional suficiente, ela pode ser destacada.
A resposta dos instrumentos de contorno também segue um vetor claro - ofuscação, que não tem uma assinatura estável. Protocolos como AmneziaWG (WireGuard ofuscado) adicionam ruído aleatório ao tráfego, randomizam os tamanhos e tempos dos pacotes para que a conexão não tenha um perfil estatístico estável. Este é um contra-ataque direto contra a detecção estatística: se o perfil for diferente cada vez, é difícil construir uma referência para comparação.
Esta é a dinâmica clássica da resistência à censura: os detectores procuram invariantes, as ferramentas de contorno as eliminam, os detectores procuram novas. Academicamente, isso é bem descrito em trabalhos sobre detecção e ofuscação de protocolos - por exemplo, estudos do grupo Tor sobre transportes plugáveis, trabalhos sobre a detecção de Shadowsocks pelo GFW chinês.
Limitação do lado do hardware
Há outro lado, sem o qual o quadro está incompleto - o custo da detecção.
A análise do TLS handshake é barata: olhou para os primeiros poucos pacotes da conexão, calculou o hash, comparou com a base. Isso pode ser feito em tempo real para todo o tráfego.
A análise estatística do comportamento é mais cara.
Para construir um histograma dos tamanhos de pacotes e um perfil de tempos, você precisa rastrear a conexão ao longo do tempo, acumular estado, calcular estatísticas. Isso requer memória para cada conexão e cálculos. Com milhões de conexões simultâneas, a carga no equipamento aumenta exponencialmente.
Em abril de 2026, houve um episódio revelador: ao tentar sobrecarregar o TSPU com um grande número de regras de filtragem (de acordo com publicações, cerca de 40 mil contra os habituais 10-15 mil), o sistema em parte dos nós entrou em bypass - ou seja, começou a passar tráfego sem filtragem, incluindo recursos previamente bloqueados. Esta é uma consequência direta do fato de que a análise profunda é intensiva em recursos, e a largura de banda total do equipamento é finita.
Resulta em um paradoxo interessante, que os especialistas notaram: quanto mais usuários ativam proxies, maior a carga no sistema de filtragem, pior ele lida com todo o resto. A detecção por estatísticas intensifica esse efeito, porque é mais cara do que uma simples verificação de handshake.
O que é verdade na notícia original e o que é um exagero
Já que a ocasião é uma notícia específica, vou analisar suas formulações do ponto de vista técnico.
"O DPI analisa não apenas o handshake, mas também as assinaturas do protocolo - tamanho dos pacotes, impressão digital"
isso é tecnicamente correto. É a transição da análise de handshake para a análise de estatísticas comportamentais que é a essência da nova rodada.
"Se diferentes clientes se conectam ao mesmo IP com a mesma versão desatualizada do navegador - este é um sinal de um proxy"
correto e lógico. Esta é a mesma correlação comportamental por IP, um marcador forte e barato para calcular.
"É impossível evitar isso agora"
exagero. Mais precisamente, "é impossível evitar a correção cosmética da impressão digital". A detecção estatística é contornada pela ofuscação com randomização, e esses métodos existem (AmneziaWG como exemplo). A corrida continua, e não terminou.
"O Telegram deve reprocessar completamente os protocolos"
parcialmente verdade. Para que o Fake-TLS volte a ser indistinguível, você precisa mudar não a impressão digital, mas a forma como o tráfego é formado - isso é mais profundo do que substituir um hash. Mas "reprocessar completamente" é uma dramatização.
Uma imagem típica para notícias técnicas: os fatos principais são verdadeiros, as conclusões são dramatizadas ao nível de "tudo está perdido".
O que é útil tirar disso
Alguns pensamentos que vão além do caso específico com o Telegram.
A criptografia da carga útil não esconde os metadados do tráfego.
Este é um princípio fundamental. Você pode criptografar perfeitamente o conteúdo, mas os tamanhos dos pacotes, tempos, direção, duração da conexão permanecem visíveis. A análise de tráfego (análise de tráfego) é uma disciplina poderosa separada, e ela funciona em cima de qualquer criptografia. Isso se aplica não apenas ao contorno da censura, mas também, por exemplo, à desanonimização no Tor por tempos e vazamentos em mensageiros criptografados por meio de tamanhos de pacotes.
Uma impressão digital estática é fácil de falsificar, o comportamento dinâmico é difícil.
Este é um princípio geral para qualquer detecção. Uma assinatura que pode ser copiada uma vez é uma proteção fraca. Invariantes comportamentais gerados pela própria lógica do sistema - um sinal muito mais estável. Isso se aplica a anti-fraude, detecção de bots e impressão digital de dispositivos.
Qualquer detecção repousa no custo.
Quanto mais profunda a análise, mais cara ela é computacionalmente. Isso cria um limite fundamental: o sistema pode ser sobrecarregado pelo volume. A proteção e o ataque aqui são sempre também a economia de cálculos, não apenas algoritmos.
A ofuscação contra assinaturas é sobre a eliminação de invariantes.
A melhor maneira de não ser pego por estatísticas é não ter estatísticas estáveis. Randomização de tamanhos, tempos, adição de ruído. Este é um contra-ataque que funciona contra qualquer detector que procure um padrão estável.
Resumo
O que aconteceu em maio de 2026 com o MTProxy é a transição da detecção do nível "como o início da conexão se parece" para o nível "como a conexão se comporta ao longo do tempo". Tecnicamente, este é um passo natural: a análise de handshake é contornada pela falsificação da impressão digital, então o regulador passou para a análise estatística, que é mais difícil de falsificar.
Este não é o "fim do Telegram" e não "é impossível contornar" - esta é uma nova rodada da antiga corrida entre detecção e ofuscação de protocolos. A detecção estatística, por sua vez, é contornada pela randomização do tráfego, e as ferramentas para isso já existem. Paralelamente, todo o sistema repousa no teto do poder computacional - a análise profunda é cara, e esta é uma restrição objetiva.
Do ponto de vista puramente da engenharia, esta é uma bela tarefa na interseção da análise de rede, estatística e teoria da detecção. E a compreensão de sua mecânica é útil muito além do tema dos bloqueios - os mesmos princípios funcionam em análise de tráfego, anti-fraude, detecção de bots e análise de canais criptografados.
Esta é uma análise técnica da mecânica da detecção de protocolos, não uma declaração política e não um guia sobre como contornar os bloqueios. Se você tiver correções na parte técnica - escreva nos comentários.
Fontes e para leitura adicional:
Documentação sobre impressão digital JA3/JA4 (Salesforce, FoxIO)
Pesquisa do Projeto Tor sobre transportes plugáveis e detecção de obfs4
Trabalhos sobre a detecção de Shadowsocks pelo sistema GFW (várias publicações acadêmicas sobre medição de censura)
Especificação MTProto na documentação aberta do Telegram
Tags:
DPI
MTProto
TSPU
traffic analysis
JA3
fingerprinting
segurança de rede
detecção de protocolos
📤 Compartilhar & Baixar
🧰 Ferramentas recomendadas
Divulgação: alguns links são patrocinados. Podemos receber comissão se você comprar — sem custo extra para você. Só indicamos o que faz sentido para a comunidade.
