Perguntas sobre HTTPS e os servidores DNS do Google: vamos esclarecer

Embora os servidores DNS do Google (8.8.8.8, 8.8.4.4) resolvam nomes de domínio com eficiência, inclusive os de sites HTTPS, eles não criptografam por padrão as próprias consultas DNS nem descriptografam o tráfego HTTPS subsequente. São camadas de segurança distintas: o DNS traduz nomes de domínio legíveis por humanos em endereços IP, e o HTTPS criptografa a troca de dados propriamente dita entre o seu dispositivo e o servidor do site depois que essa resolução acontece.

Entendendo os fundamentos: DNS e HTTPS

Para compreender plenamente as nuances de como o DNS do Google interage com o HTTPS, precisamos primeiro estabelecer um entendimento claro desses dois protocolos fundamentais da internet.

O que é DNS? (Domain Name System)

O Domain Name System (DNS) funciona como a lista telefônica da internet. Todo dispositivo conectado à internet tem um endereço IP único (por exemplo, 192.0.2.1 ou 2001:0db8::1). Os sites, porém, são acessados por nomes de domínio fáceis de memorizar, como gproxy.net. O DNS é o sistema que traduz esses nomes de domínio nos endereços IP correspondentes, permitindo que o seu navegador localize e se conecte ao servidor correto.

O processo de resolução DNS normalmente envolve várias etapas:

1. Consulta do cliente: quando você digita gproxy.net no navegador, o seu sistema operacional primeiro verifica o cache DNS local.
2. Resolvedor recursivo: se não for encontrado localmente, a consulta é enviada a um resolvedor DNS recursivo configurado (muitas vezes fornecido pelo seu ISP, ou um público como o DNS do Google 8.8.8.8).
3. Servidores raiz: o resolvedor recursivo então consulta um dos 13 servidores DNS raiz para encontrar os servidores de nomes autoritativos do domínio de topo (TLD), neste caso .com.
4. Servidores de nomes de TLD: os servidores de nomes do TLD apontam para os servidores de nomes autoritativos de gproxy.net.
5. Servidores de nomes autoritativos: esses servidores mantêm os registros DNS reais de gproxy.net e devolvem o endereço IP ao resolvedor recursivo.
6. Resposta ao cliente: o resolvedor recursivo envia o endereço IP de volta ao seu cliente, que então inicia a conexão.

Tradicionalmente, as consultas DNS são enviadas como pacotes UDP sem criptografia na porta 53. Isso as torna vulneráveis a diversos ataques:

• Escuta (eavesdropping): qualquer pessoa no caminho da rede pode ver quais sites você está tentando visitar.
• DNS spoofing / envenenamento de cache: agentes maliciosos podem injetar registros DNS forjados no cache de um resolvedor, redirecionando usuários para sites fraudulentos mesmo que eles digitem o domínio correto.
• Censura: ISPs ou governos podem bloquear o acesso a determinados sites manipulando as respostas DNS.

O que é HTTPS? (Hypertext Transfer Protocol Secure)

O HTTPS é a versão segura do HTTP, o protocolo pelo qual os dados são enviados entre o seu navegador e o site ao qual você se conecta. O "S" significa "Secure" (seguro) e é sustentado pelo Transport Layer Security (TLS), antigamente conhecido como Secure Sockets Layer (SSL). O HTTPS garante três propriedades de segurança críticas para a comunicação web:

• Criptografia: todos os dados trocados entre o seu navegador e o servidor são criptografados, tornando-os ilegíveis para quem intercepta o tráfego. Isso protege informações sensíveis como credenciais de login, números de cartão de crédito e dados pessoais.
• Integridade dos dados: o HTTPS garante que os dados não foram adulterados durante o trânsito. Qualquer alteração seria detectada e a conexão seria encerrada.
• Autenticação: o HTTPS verifica a identidade do servidor do site usando certificados digitais. Isso impede ataques man-in-the-middle (MITM), em que um invasor tenta se passar por um site legítimo.

O handshake TLS é um processo complexo que ocorre antes do envio de qualquer dado de aplicação:

1. Client Hello: o seu navegador envia uma mensagem "Client Hello", detalhando as versões de TLS suportadas, os conjuntos de cifras e um número aleatório.
2. Server Hello: o servidor responde com um "Server Hello", escolhendo uma versão de TLS e um conjunto de cifras compatíveis, o seu próprio número aleatório e o seu certificado digital.
3. Verificação do certificado: o seu navegador verifica o certificado do servidor junto a uma Autoridade Certificadora (CA) confiável. Se for válido, ele confia na identidade do servidor.
4. Troca de chaves: usando os números aleatórios e algoritmos criptográficos, cliente e servidor negociam e estabelecem uma "chave de sessão" compartilhada.
5. Comunicação criptografada: toda a troca de dados subsequente é criptografada com essa chave de sessão.

O HTTPS opera na porta TCP 443, ao contrário da porta 80 do HTTP. Fundamentalmente, o HTTPS oferece criptografia de ponta a ponta entre o seu navegador e o servidor do site. O processo de resolução DNS, embora seja um pré-requisito, é uma etapa separada que acontece antes mesmo de a conexão HTTPS ser iniciada.

DNS do Google (8.8.8.8 e 8.8.4.4): o que é e o que não é

O Google Public DNS é um serviço global e gratuito de resolução DNS que o Google lançou em 2009. Seus objetivos principais são oferecer uma alternativa mais rápida, mais segura e mais confiável a muitos resolvedores DNS fornecidos por ISPs.

O resolvedor DNS público

Os servidores DNS do Google, 8.8.8.8 e 8.8.4.4, são muito populares por várias vantagens:

• Desempenho: o Google usa uma rede anycast global, o que significa que, ao consultar 8.8.8.8, a sua requisição é roteada para o data center do Google mais próximo. Isso costuma resultar em menor latência e carregamento de página mais rápido em comparação com resolvedores de ISP distantes ou sobrecarregados.
• Confiabilidade: com a vasta infraestrutura do Google, o serviço de DNS oferece alta disponibilidade e redundância.
• Segurança (DNSSEC): o Google Public DNS oferece suporte completo a DNSSEC (DNS Security Extensions), que ajuda a proteger contra DNS spoofing e envenenamento de cache ao assinar criptograficamente os registros DNS. No entanto, o DNSSEC apenas verifica a integridade e a autenticidade dos dados DNS; ele não criptografa as consultas DNS em si.

Em relação à privacidade, o Google afirma coletar informações limitadas das consultas DNS. Ele registra temporariamente o seu endereço IP (normalmente por 24 a 48 horas) para fins de depuração e segurança, e depois o anonimiza. Também retém indefinidamente informações não identificáveis pessoalmente (como os nomes de domínio solicitados) para melhorar o serviço e combater ameaças como ataques DDoS. Embora isso geralmente seja melhor do que algumas práticas de ISPs, ainda envolve confiar os dados das suas consultas DNS ao Google.

O DNS do Google criptografa minhas consultas?

Esta é uma distinção crítica. Quando você configura o seu dispositivo para usar 8.8.8.8 ou 8.8.4.4 como resolvedor DNS tradicional, as suas consultas DNS são enviadas por UDP (ou às vezes TCP) na porta 53, sem criptografia. Isso significa que qualquer um que observe o seu tráfego de rede (por exemplo, o seu ISP, um administrador da rede local ou um invasor) ainda pode ver os nomes de domínio que você está resolvendo.

Ainda assim, o Google tem sido um forte defensor e adotante inicial dos protocolos de DNS criptografado:

• DNS-over-HTTPS (DoH): o Google Public DNS suporta DoH, que criptografa as consultas DNS encapsulando-as em tráfego HTTPS. Isso faz com que as suas requisições DNS pareçam tráfego web comum (na porta 443) e sejam muito mais difíceis de distinguir, interceptar ou bloquear.
• DNS-over-TLS (DoT): o Google Public DNS também suporta DoT, que criptografa as consultas DNS usando TLS diretamente em uma porta dedicada (geralmente a 853). O DoT oferece benefícios de privacidade semelhantes aos do DoH, mas usa uma porta distinta, o que facilita a identificação e a eventual gestão do tráfego DNS por administradores de rede.

Portanto, simplesmente usar 8.8.8.8 não criptografa as suas consultas DNS. Você precisa configurar explicitamente o seu sistema operacional, navegador ou roteador para usar os endpoints DoH ou DoT do Google e assim se beneficiar da privacidade das consultas DNS criptografadas. Este é um ponto crucial e frequentemente mal compreendido.

A interação: como o DNS do Google e o HTTPS trabalham juntos (e separadamente)

Entender a sequência dos eventos é essencial para compreender os papéis do DNS e do HTTPS.

O processo de resolução para um site HTTPS

Vamos acompanhar o que acontece quando você acessa https://www.securebank.com:

1. Consulta DNS: o seu navegador envia uma consulta DNS para www.securebank.com ao resolvedor DNS configurado (por exemplo, o DNS do Google 8.8.8.8). Essa consulta, a menos que você use DoH/DoT, não é criptografada.
2. Endereço IP recebido: o resolvedor DNS devolve ao seu navegador o endereço IP de www.securebank.com (por exemplo, 203.0.113.42).
3. Conexão TCP: o seu navegador inicia uma conexão TCP com o endereço IP 203.0.113.42 na porta 443 (a porta padrão do HTTPS).
4. Handshake TLS: assim que a conexão TCP é estabelecida, começa o handshake TLS. Isso envolve a troca de certificados, a negociação de conjuntos de cifras e o estabelecimento de uma chave secreta compartilhada.
5. Transferência de dados criptografada: após um handshake bem-sucedido, toda a troca de dados subsequente – suas credenciais de login, detalhes da conta e todo o conteúdo do site – é criptografada com a chave de sessão acordada.

Por essa sequência fica claro: a resolução DNS acontece primeiro e é pré-requisito para estabelecer qualquer conexão, inclusive uma HTTPS. Em seguida, o HTTPS assume para proteger a troca de dados propriamente dita. O seu resolvedor DNS (o DNS do Google, neste caso) não tem papel direto no processo de criptografia ou descriptografia do HTTPS.

Implicações de segurança

A separação de responsabilidades entre DNS e HTTPS tem implicações de segurança significativas:

• Vulnerabilidades das consultas DNS: se as suas consultas DNS não forem criptografadas (usando DNS tradicional), elas podem revelar seus hábitos de navegação a terceiros. Um invasor também pode realizar DNS spoofing para redirecioná-lo a um site malicioso. Mesmo que o site malicioso não tenha um certificado HTTPS válido, alguns usuários podem ignorar os avisos do navegador. Pior: um invasor avançado pode até obter um certificado válido para um domínio parecido ou emitir um fraudulento por meio de uma CA comprometida, tornando o engano bastante convincente.
• Escopo de proteção do HTTPS: o HTTPS protege o conteúdo da sua comunicação e a integridade dos dados depois que a conexão é estabelecida. Ele verifica que você está falando com o servidor legítimo ao qual pretendia se conectar (com base no certificado). No entanto, ele não oculta a consulta DNS inicial que o levou até aquele servidor.
• Vetores de ataque combinados: um ataque sofisticado pode combinar manipulação de DNS com outras técnicas. Por exemplo, se um invasor envenenar com sucesso o seu cache DNS para apontar securebank.com ao servidor dele e conseguir provisionar um certificado SSL válido (mas fraudulento) para esse domínio, o seu navegador pode exibir um cadeado verde e ainda assim você estaria interagindo com um site controlado pelo invasor. Isso reforça a importância de uma validação robusta de certificados e, idealmente, de DNS seguro.

Privacidade avançada de DNS: DoH, DoT e seus impactos

As vulnerabilidades do DNS tradicional levaram ao desenvolvimento dos protocolos de DNS criptografado. O Google, entre outros, tem sido um ator-chave na promoção e implementação desses protocolos.

DNS-over-HTTPS (DoH)

O DoH encapsula as consultas DNS dentro do tráfego HTTPS padrão. Isso significa que as requisições DNS são enviadas pela porta TCP 443, a mesma usada na navegação web comum. Esse desenho traz várias vantagens:

• Privacidade aprimorada: como as consultas DoH são criptografadas e indistinguíveis de outro tráfego HTTPS, é muito mais difícil para ISPs ou outros observadores de rede bisbilhotar, registrar ou bloquear. Suas consultas DNS ficam escondidas no vasto fluxo de tráfego web criptografado.
• Contorno da censura: em regiões onde há censura baseada em DNS, o DoH muitas vezes consegue burlar essas restrições porque se mistura ao tráfego web normal, dificultando que censores atinjam especificamente as consultas DNS sem bloquear o acesso web legítimo.
• Segurança aprimorada: o uso de TLS fornece autenticação e verificação de integridade das respostas DNS, mitigando riscos como DNS spoofing e envenenamento de cache, de modo semelhante ao que o HTTPS faz pelo tráfego web.

No entanto, o DoH também apresenta alguns desafios:

• Preocupações com centralização: a adoção ampla de poucos grandes provedores de DoH (como Google ou Cloudflare) pode centralizar a resolução DNS, dando a esses provedores uma visão significativa dos padrões globais de navegação.
• Dificuldade de monitoramento de rede: em redes corporativas ou sistemas de controle parental, o DoH dificulta monitorar ou filtrar requisições DNS para fins de segurança ou aplicação de políticas, já que elas aparecem como tráfego web legítimo.

Muitos navegadores modernos, como Firefox e Chrome, oferecem suporte nativo a DoH, muitas vezes com Google ou Cloudflare como provedores padrão. Sistemas operacionais como Android e Windows também estão integrando opções de DoH para todo o sistema.

DNS-over-TLS (DoT)

O DoT criptografa as consultas DNS usando TLS diretamente em uma porta dedicada, normalmente a porta TCP 853. Diferentemente do DoH, que se disfarça de tráfego web, o DoT sinaliza explicitamente sua natureza de serviço DNS criptografado.

• Privacidade e segurança fortes: assim como o DoH, o DoT oferece criptografia, autenticação e integridade robustas para consultas e respostas DNS, protegendo contra escuta e adulteração.
• Porta dedicada: o uso de uma porta dedicada (853) torna o DoT mais fácil de identificar, gerenciar e eventualmente priorizar ou filtrar por administradores de rede em comparação com o DoH. Isso pode ser uma vantagem em ambientes corporativos.

A principal desvantagem do DoT em relação ao DoH é que sua porta dedicada facilita o bloqueio por firewalls ou censores que miram especificamente o tráfego DNS.

O Google Public DNS suporta tanto DoH quanto DoT. Você pode configurar seus dispositivos para usar esses endpoints criptografados em vez do tradicional 8.8.8.8 sem criptografia. Por exemplo, o endpoint DoH do Google é https://dns.google/resolve, e o endpoint DoT é dns.google na porta 853.

Serviços de proxy e DNS/HTTPS: reforçando segurança e privacidade (foco em GProxy)

Quando você introduz um serviço de proxy como o GProxy na sua arquitetura de rede, a interação com DNS e HTTPS fica mais sutil e costuma acrescentar camadas extras de segurança e privacidade.

Como os proxies interagem com o DNS

Um servidor proxy atua como intermediário entre o seu cliente e a internet. Ao usar um proxy, o caminho da sua resolução DNS muda:

1. Seu cliente envia uma requisição (por exemplo, para gproxy.net) ao servidor GProxy.
2. O servidor GProxy, e não a sua máquina local, faz a consulta DNS. Ele pode ser configurado para usar qualquer resolvedor DNS, incluindo o DNS do Google ou até mesmo os endpoints DoH/DoT do Google.
3. Assim que o servidor GProxy resolve o domínio para um endereço IP, ele estabelece a conexão com o servidor de destino em seu nome.

Essa configuração significa que a sua rede local (ISP, roteador) vê apenas consultas DNS direcionadas ao próprio servidor GProxy, e não ao site de destino final. A consulta DNS real para o site de destino parte da rede do servidor GProxy. Isso aumenta a sua privacidade ao ocultar a sua atividade DNS direta dos observadores da rede local.

O GProxy, com sua infraestrutura robusta, pode ser configurado para usar por padrão resolvedores DNS seguros, como os servidores DoH/DoT do Google, para todas as requisições de clientes roteadas por ele. Isso garante que até as consultas DNS do proxy sejam criptografadas e protegidas contra vigilância.

HTTPS e proxies: o desafio do SNI

O tráfego HTTPS é criptografado de ponta a ponta, o que significa que um proxy padrão (como um proxy SOCKS5 ou um proxy transparente) normalmente não consegue ver nem modificar o conteúdo criptografado. O proxy apenas encaminha os bytes criptografados entre o seu cliente e o servidor de destino. Em geral, isso é bom para a privacidade.

No entanto, há uma informação específica que pode vazar mesmo com HTTPS: o Server Name Indication (SNI). O SNI é uma extensão do protocolo TLS que permite ao cliente indicar a qual hostname ele está tentando se conectar no início do handshake TLS. Isso é essencial para servidores que hospedam vários sites em um único endereço IP (hospedagem virtual). Infelizmente, o SNI é enviado em texto claro durante o handshake TLS inicial, antes de a criptografia estar totalmente estabelecida.

Isso significa que, mesmo que o seu tráfego seja criptografado por HTTPS e roteado por um proxy, um observador no caminho da rede (por exemplo, o seu ISP ou até o provedor de proxy, se mal escolhido) poderia potencialmente ver os nomes de domínio dos sites HTTPS que você visita ao inspecionar o campo SNI. Embora o conteúdo da sua comunicação permaneça seguro, o domínio de destino em si pode ser revelado.

A vantagem do GProxy na gestão de DNS e HTTPS

O GProxy enfrenta esses desafios oferecendo recursos avançados que aumentam a privacidade e a segurança tanto do tráfego DNS quanto do HTTPS:

• Resolução DNS criptografada: os servidores do GProxy podem ser configurados para usar exclusivamente resolvedores DoH ou DoT em todas as consultas DNS originadas no proxy. Isso garante que até as consultas DNS do proxy sejam privadas, acrescentando uma camada extra de proteção além do simples uso de um DNS público.
• Ofuscação de tráfego e tunelamento: ao rotear todo o seu tráfego pelos túneis seguros do GProxy, o seu ISP vê apenas conexões criptografadas com o servidor GProxy, e não com o destino final. Isso ofusca a sua atividade online, dificultando a identificação de padrões específicos de navegação.
• Possível mascaramento de SNI (avançado): embora o SNI seja um padrão do TLS, algumas configurações avançadas de proxy ou VPNs em camadas com proxies podem ajudar a mitigar o vazamento de SNI. Por exemplo, roteando o tráfego por uma cadeia de proxies ou usando implementações específicas de cliente TLS, é possível ocultar o SNI original de observadores intermediários. O GProxy avalia e implementa continuamente técnicas avançadas desse tipo para aumentar a privacidade dos usuários.
• Desbloqueio geográfico e acesso: muitos serviços com restrição geográfica dependem da localização baseada em IP e, com frequência, da resolução DNS. Usando o GProxy, você pode rotear seu tráfego por um servidor em outra localização geográfica, contornando essas restrições de forma eficaz. Isso é particularmente útil para acessar conteúdo ou serviços bloqueados por região que fazem consultas DNS para verificar a sua localização. Por exemplo, se um serviço de streaming verifica seu IP e seu resolvedor DNS para determinar a sua região, usar um servidor GProxy no país-alvo, que por sua vez usa um resolvedor DoH local, pode garantir acesso sem atritos.

Considere um cenário: um usuário no País A quer acessar um serviço disponível apenas no País B. O serviço verifica o endereço IP do usuário e também realiza consultas DNS para garantir consistência. Ao se conectar a um servidor GProxy localizado no País B, com esse servidor GProxy configurado para usar um endpoint DoH do Google (ou outro resolvedor DoH seguro) também localizado no País B, o usuário aparenta efetivamente ser um usuário legítimo do País B, com todo o tráfego e todas as consultas DNS tratados de forma segura e local dentro do ecossistema de internet do País B.

import dns.resolver
import dns.query
import dns.message
import requests # Required for DoH

def resolve_domain_doh(domain, doh_resolver_url="https://dns.google/resolve"):
    """
    Resolves a domain using DNS-over-HTTPS (DoH) via a specified resolver.
    Requires 'dnspython' and 'requests' libraries.
    """
    try:
        # Create a resolver object for DoH
        resolver = dns.resolver.Resolver(configure=False)
        resolver.nameservers = [] # Clear default nameservers to ensure DoH is used

        # Use Google's DoH endpoint
        resolver.use_https(doh_resolver_url)

        print(f"Attempting to resolve '{domain}' via DoH using {doh_resolver_url}...")
        answers = resolver.resolve(domain, 'A')

        print(f"IP addresses for {domain}:")
        for rdata in answers:
            print(f"- {rdata.address}")
        return [rdata.address for rdata in answers]
    except dns.resolver.NXDOMAIN:
        print(f"Error: Domain '{domain}' not found.")
    except Exception as e:
        print(f"An error occurred during DoH resolution: {e}")
    return []

# Example usage:
if __name__ == "__main__":
    target_domain = "gproxy.net" # Using GProxy's domain as an example

    # Resolve via Google's DoH
    resolve_domain_doh(target_domain)

    print("\n--- Traditional DNS Lookup (for comparison) ---")
    try:
        # For traditional DNS, dnspython will use system configured resolvers
        # or fall back to default if none are set.
        traditional_answers = dns.resolver.resolve(target_domain, 'A')
        print(f"IP addresses for {target_domain} (Traditional DNS):")
        for rdata in traditional_answers:
            print(f"- {rdata.address}")
    except Exception as e:
        print(f"Traditional DNS lookup failed: {e}")

    # Example of how a client might use a proxy for an HTTPS request
    # This is conceptual, as actual proxy configuration depends on client software.
    print("\n--- Conceptual HTTPS request through a proxy ---")
    proxy_url = "http://your_gproxy_ip:port" # Replace with actual GProxy details
    proxies = {
        "http": proxy_url,
        "https": proxy_url,
    }

    try:
        # requests library will handle DNS resolution via the proxy if configured
        # and then establish an HTTPS connection.
        print(f"Attempting to fetch {target_domain} via proxy {proxy_url}...")
        # For simplicity, we're assuming the proxy is configured to handle DNS securely
        # and forward HTTPS traffic.
        response = requests.get(f"https://{target_domain}", proxies=proxies, timeout=10)
        print(f"Status Code for {target_domain}: {response.status_code}")
        # print(f"First 200 characters of response: {response.text[:200]}...")
    except requests.exceptions.ProxyError as pe:
        print(f"Proxy connection error: {pe}")
    except requests.exceptions.ConnectionError as ce:
        print(f"Connection error (check proxy or network): {ce}")
    except Exception as e:
        print(f"An error occurred during HTTPS request via proxy: {e}")

Tabela comparativa: DNS tradicional vs. DoH vs. DoT

Resumindo as principais diferenças entre os protocolos DNS:

Principais conclusões

Navegar pelas complexidades de protocolos de internet como DNS e HTTPS é essencial para manter segurança e privacidade online. Entender seus papéis distintos e como eles interagem, especialmente com serviços como o DNS do Google e provedores de proxy, permite que os usuários tomem decisões mais informadas.

• DNS e HTTPS são camadas distintas: o DNS traduz nomes de domínio em endereços IP, enquanto o HTTPS criptografa a troca de dados *depois* dessa tradução. Usar o DNS do Google (8.8.8.8) da forma tradicional não criptografa as suas consultas DNS nem afeta a criptografia HTTPS; ele apenas oferece um serviço de resolução rápido e confiável.
• Adote o DNS criptografado: para ter privacidade real nas consultas DNS, vá além do DNS tradicional. Use DNS-over-HTTPS (DoH) ou DNS-over-TLS (DoT). O Google Public DNS suporta ambos, oferecendo um avanço significativo na proteção da sua atividade de navegação contra escuta e manipulação.
• Proxies reforçam a cadeia de segurança: um serviço de proxy confiável como o GProxy pode fortalecer bastante a sua postura geral de privacidade e segurança. Ao rotear seu tráfego pelo GProxy, suas consultas DNS diretas são mascaradas, e o próprio proxy pode ser configurado para usar DNS criptografado (DoH/DoT), garantindo que até as consultas intermediárias sejam seguras. Isso cria uma defesa robusta e em várias camadas contra vigilância e censura.

Dicas práticas:

1. Configure DoH/DoT: sempre que possível, configure o seu navegador, sistema operacional ou roteador para usar DoH ou DoT. Muitos navegadores oferecem isso diretamente nas configurações de privacidade (por exemplo, "DNS criptografado" no Firefox ou "DNS seguro" no Chrome). Para proteção em todo o sistema, explore as configurações de DoH/DoT no nível do sistema operacional ou use ferramentas como systemd-resolved no Linux.
2. Sempre verifique o HTTPS: confira sempre o ícone do cadeado e certifique-se de que os sites usam HTTPS, especialmente ao lidar com informações sensíveis. Desconfie de avisos de certificado; eles costumam indicar um possível problema de segurança.
3. Use o GProxy para proteção abrangente: para privacidade avançada, desbloqueio geográfico e uma abordagem unificada de conexões seguras, integre o GProxy ao seu fluxo de trabalho. O GProxy pode garantir que o seu tráfego seja roteado por túneis seguros, e seus servidores podem ser configurados para usar resolvedores DNS criptografados, oferecendo uma solução de privacidade aprimorada de ponta a ponta que vai além do que configurações isoladas de DNS ou HTTPS conseguem entregar sozinhas.