Ocultando Metadados em Mensageiros: 2-Hop Onion-Lite sobre VLESS + Reality Relay e Por Que é Quase Gratuito
Este artigo detalha uma nova abordagem para aprimorar a privacidade em aplicativos de mensagens, implementando um sistema de roteamento 2-hop onion-lite sobre a infraestrutura existente de VLESS + Reality. A solução visa proteger os metadados do usuário, impedindo que um único relay identifique tanto a origem quanto o destino do tráfego, com um impacto mínimo nos custos operacionais.
MundiX News·16 de junho de 2026·15 min de leitura·👁 4 views
Em artigos anteriores, exploramos como integramos o bypass de bloqueios diretamente em um aplicativo iOS, utilizando sing-box, VLESS + Reality e relays como componentes descartáveis, com configurações separadas da compilação. Essa solução abordava a tarefa de direcionar o tráfego de um mensageiro para um servidor em cenários onde a conexão direta é restrita. No entanto, uma preocupação persistente era a visibilidade dos metadados. Um único relay, mesmo com o túnel VLESS + Reality, ainda podia observar o IP do cliente, o endereço do servidor de destino (ilha) e o timing das conexões. Essa informação, embora não revele o conteúdo da mensagem (protegido por criptografia de ponta a ponta e Sealed Sender), é suficiente para vincular um usuário a um serviço específico, o que pode ser crítico sob censura.
A vulnerabilidade reside no fato de que o relay é o ponto mais exposto da infraestrutura. Se um relay for comprometido ou seu operador for coagido, os metadados de todos os usuários que passaram por ele podem ser expostos. Isso se torna particularmente problemático com planos futuros de permitir que voluntários hospedem relays (o "track Hydra"). Um relay doméstico de voluntário, operando em um modelo single-hop, veria os mesmos metadados e poderia ser comprometido, expondo os usuários que ele deveria proteger. Para mitigar isso, foi desenvolvida uma solução estrutural: o roteamento 2-hop onion-lite.
A arquitetura 2-hop onion-lite utiliza dois relays em cadeia: Cliente → ENTRY Relay → (túnel opaco) → EXIT Relay → Ilha. Essa configuração explora a funcionalidade detour do sing-box, onde o cliente estabelece dois túneis de saída. O túnel para o EXIT Relay é marcado como detour: onion-entry, o que significa que a conexão não vai diretamente para a rede, mas é encapsulada dentro do túnel para o ENTRY Relay. O endereço da ilha é solicitado na camada de saída, que só pode ser descriptografada pelo EXIT Relay. O ENTRY Relay vê o IP do cliente e a necessidade de enviar bytes para o EXIT Relay, mas não pode ler o endereço da ilha, pois não possui a chave privada do Reality do EXIT Relay. Por outro lado, o EXIT Relay vê o IP do ENTRY Relay e o endereço da ilha, mas não o IP do cliente original. Essa separação é criptográfica, garantindo que nenhum relay individual possa correlacionar a origem e o destino do tráfego.
A implementação dessa solução foi notavelmente econômica. Os relays existentes não exigiram nenhuma reconfiguração, pois já operavam com direct outbound sem regras de roteamento complexas. Para o ENTRY Relay, a conexão VLESS para outro relay é tratada como uma conexão de cliente comum. O EXIT Relay também vê uma conexão VLESS padrão vinda do ENTRY Relay. A cadeia é invisível para os próprios relays, que não sabem que fazem parte de um roteamento onion. Além disso, a funcionalidade xtls-rprx-vision funciona sobre detour, eliminando a necessidade de variantes de inbound separadas sem vision para relays intermediários ou de saída. Um protótipo local com curl para api.rcq.app/health mostrou um aumento na latência de 0.27s para 0.98s, um custo aceitável para a melhoria na privacidade. A configuração do cliente envolve dois túneis de saída VLESS com detour e um urltest para gerenciar os relays de saída. A escolha do ENTRY Relay é persistente (sticky entry guard), semelhante ao Tor, para evitar que observadores forcem a rotação do nó de entrada. Os relays de saída, por outro lado, são rotacionados dinamicamente com base na saúde da rota. A entrega de configurações é feita de forma dinâmica, sem a necessidade de novas compilações do aplicativo, permitindo a ativação gradual do modo onion para grupos específicos de usuários e a reversão rápida em caso de problemas.
É crucial entender as limitações desta abordagem. Não se trata de um "cliente leve" no sentido de que o primeiro hop (cliente para ENTRY Relay) ainda utiliza protocolos pesados como Reality ou Hy2. Ambos os relays atualmente pertencem à mesma infraestrutura, o que significa que o operador (RCQ) ainda tem visibilidade sobre ambos os extremos, embora separados. A proteção é contra um único relay comprometido ou coagido, não contra o operador da infraestrutura ou um observador global passivo. A detecção de IP e DPI ainda são possíveis, e a latência aumenta devido ao hop extra. O modo onion é desativado por padrão e sua ativação é feita de forma controlada e gradual. A estratégia é clara: primeiro o onion, depois a abertura para relays de voluntários (Hydra), pois o onion quebra a ligação de metadados, tornando seguro o uso de relays externos. A lição principal é que metadados são uma camada de ameaça distinta do bypass de bloqueios, que funcionalidades existentes podem ser aproveitadas, e que a persistência do nó de entrada é crucial para a segurança. A implementação no mensageiro RCQ, com código aberto para iOS, permite a verificação direta da arquitetura.
🛡️⚡
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
Em artigos anteriores, exploramos como integramos o bypass de bloqueios diretamente em um aplicativo iOS, utilizando sing-box, VLESS + Reality e relays como componentes descartáveis, com configurações separadas da compilação. Essa solução abordava a tarefa de direcionar o tráfego de um mensageiro para um servidor em cenários onde a conexão direta é restrita. No entanto, uma preocupação persistente era a visibilidade dos metadados. Um único relay, mesmo com o túnel VLESS + Reality, ainda podia observar o IP do cliente, o endereço do servidor de destino (ilha) e o timing das conexões. Essa informação, embora não revele o conteúdo da mensagem (protegido por criptografia de ponta a ponta e Sealed Sender), é suficiente para vincular um usuário a um serviço específico, o que pode ser crítico sob censura.
A vulnerabilidade reside no fato de que o relay é o ponto mais exposto da infraestrutura. Se um relay for comprometido ou seu operador for coagido, os metadados de todos os usuários que passaram por ele podem ser expostos. Isso se torna particularmente problemático com planos futuros de permitir que voluntários hospedem relays (o "track Hydra"). Um relay doméstico de voluntário, operando em um modelo single-hop, veria os mesmos metadados e poderia ser comprometido, expondo os usuários que ele deveria proteger. Para mitigar isso, foi desenvolvida uma solução estrutural: o roteamento 2-hop onion-lite.
A arquitetura 2-hop onion-lite utiliza dois relays em cadeia: Cliente → ENTRY Relay → (túnel opaco) → EXIT Relay → Ilha. Essa configuração explora a funcionalidade detour do sing-box, onde o cliente estabelece dois túneis de saída. O túnel para o EXIT Relay é marcado como detour: onion-entry, o que significa que a conexão não vai diretamente para a rede, mas é encapsulada dentro do túnel para o ENTRY Relay. O endereço da ilha é solicitado na camada de saída, que só pode ser descriptografada pelo EXIT Relay. O ENTRY Relay vê o IP do cliente e a necessidade de enviar bytes para o EXIT Relay, mas não pode ler o endereço da ilha, pois não possui a chave privada do Reality do EXIT Relay. Por outro lado, o EXIT Relay vê o IP do ENTRY Relay e o endereço da ilha, mas não o IP do cliente original. Essa separação é criptográfica, garantindo que nenhum relay individual possa correlacionar a origem e o destino do tráfego.
A implementação dessa solução foi notavelmente econômica. Os relays existentes não exigiram nenhuma reconfiguração, pois já operavam com direct outbound sem regras de roteamento complexas. Para o ENTRY Relay, a conexão VLESS para outro relay é tratada como uma conexão de cliente comum. O EXIT Relay também vê uma conexão VLESS padrão vinda do ENTRY Relay. A cadeia é invisível para os próprios relays, que não sabem que fazem parte de um roteamento onion. Além disso, a funcionalidade xtls-rprx-vision funciona sobre detour, eliminando a necessidade de variantes de inbound separadas sem vision para relays intermediários ou de saída. Um protótipo local com curl para api.rcq.app/health mostrou um aumento na latência de 0.27s para 0.98s, um custo aceitável para a melhoria na privacidade. A configuração do cliente envolve dois túneis de saída VLESS com detour e um urltest para gerenciar os relays de saída. A escolha do ENTRY Relay é persistente (sticky entry guard), semelhante ao Tor, para evitar que observadores forcem a rotação do nó de entrada. Os relays de saída, por outro lado, são rotacionados dinamicamente com base na saúde da rota. A entrega de configurações é feita de forma dinâmica, sem a necessidade de novas compilações do aplicativo, permitindo a ativação gradual do modo onion para grupos específicos de usuários e a reversão rápida em caso de problemas.
É crucial entender as limitações desta abordagem. Não se trata de um "cliente leve" no sentido de que o primeiro hop (cliente para ENTRY Relay) ainda utiliza protocolos pesados como Reality ou Hy2. Ambos os relays atualmente pertencem à mesma infraestrutura, o que significa que o operador (RCQ) ainda tem visibilidade sobre ambos os extremos, embora separados. A proteção é contra um único relay comprometido ou coagido, não contra o operador da infraestrutura ou um observador global passivo. A detecção de IP e DPI ainda são possíveis, e a latência aumenta devido ao hop extra. O modo onion é desativado por padrão e sua ativação é feita de forma controlada e gradual. A estratégia é clara: primeiro o onion, depois a abertura para relays de voluntários (Hydra), pois o onion quebra a ligação de metadados, tornando seguro o uso de relays externos. A lição principal é que metadados são uma camada de ameaça distinta do bypass de bloqueios, que funcionalidades existentes podem ser aproveitadas, e que a persistência do nó de entrada é crucial para a segurança. A implementação no mensageiro RCQ, com código aberto para iOS, permite a verificação direta da arquitetura.
📤 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.
