HTTPS: protocolo de segurança e seu papel nas operações de proxy

O HTTPS, a evolução segura do HTTP, é fundamentalmente um protocolo de segurança que criptografa a comunicação entre um cliente e um servidor, protegendo a integridade e a confidencialidade dos dados. Nas operações de proxy, o HTTPS apresenta um desafio e uma oportunidade únicos: enquanto os proxies padrão normalmente encaminham o tráfego criptografado como um túnel opaco, configurações avançadas de proxy podem aproveitar o HTTPS para obter mais segurança, desempenho ou inspeção profunda de conteúdo, alterando de forma fundamental como os dados fluem e são processados.

Entendendo o HTTPS: além do cadeado verde

HTTPS (Hypertext Transfer Protocol Secure) é a espinha dorsal da comunicação segura na internet. Sua presença onipresente, simbolizada pelo ícone de cadeado na barra de endereços do navegador, indica um canal seguro, protegendo dados sensíveis contra escuta e adulteração. Entender seus mecanismos internos é essencial para quem opera ou utiliza serviços de proxy.

A evolução do HTTP para o HTTPS

O protocolo HTTP original, desenvolvido nos primórdios da web, era por natureza sem estado e sem criptografia. Os dados trocados por HTTP eram transmitidos em texto puro, ficando vulneráveis à interceptação e à modificação por agentes maliciosos. À medida que a internet evoluiu para lidar com transações sensíveis — bancos, e-commerce, dados pessoais —, a necessidade de uma alternativa segura tornou-se prioritária. Isso levou ao desenvolvimento do HTTPS, que essencialmente coloca o protocolo Transport Layer Security (TLS) (antes SSL, Secure Sockets Layer) sobre o HTTP. A RFC 2818 do IETF, publicada em maio de 2000, especificou formalmente o uso de TLS sobre HTTP, consolidando o HTTPS como o padrão para comunicação web segura.

Componentes centrais do HTTPS

O HTTPS depende de uma interação sofisticada entre técnicas criptográficas e mecanismos de confiança:

• Protocolo TLS/SSL: esta é a camada central de criptografia. O TLS opera na camada de transporte (camada 4 do modelo OSI) e fornece três serviços principais:
  • Criptografia: embaralha os dados para impedir a leitura não autorizada. Usa uma combinação de criptografia assimétrica (chave pública) e simétrica (chave de sessão).
  • Integridade: garante que os dados não foram alterados durante o trânsito, por meio de funções de hash criptográfico (por exemplo, SHA-256).
  • Autenticação: verifica a identidade do servidor (e, opcionalmente, do cliente) para impedir personificação.
• Certificados digitais (X.509): esses documentos eletrônicos vinculam uma chave pública a uma entidade (como o servidor de um site). Emitidos por Autoridades Certificadoras (CAs) confiáveis, os certificados formam uma "cadeia de confiança". Quando um navegador se conecta a um site HTTPS, ele recebe o certificado do servidor e verifica sua autenticidade checando se foi assinado por uma CA em que confia. Os tipos comuns de certificado incluem Domain Validated (DV), Organization Validated (OV) e Extended Validation (EV).

Como funciona o handshake TLS (simplificado)

O estabelecimento de uma conexão HTTPS começa com o handshake TLS, um processo de várias etapas que negocia parâmetros de criptografia e verifica identidades:

1. Client Hello: o cliente envia uma mensagem ao servidor propondo as versões de TLS que suporta (por exemplo, TLS 1.2, TLS 1.3), as cipher suites (combinações de algoritmos de criptografia como AES-256-GCM, métodos de troca de chaves como ECDHE e algoritmos de hash) e uma sequência aleatória de bytes.
2. Server Hello: o servidor responde, selecionando a maior versão de TLS e a cipher suite suportadas por ambos, e envia sua própria sequência aleatória de bytes.
3. Certificado do servidor: o servidor envia seu certificado digital, que inclui sua chave pública.
4. Server Key Exchange (opcional): se a cipher suite escolhida exigir (por exemplo, para troca de chaves Diffie-Hellman), o servidor envia uma mensagem de troca de chaves.
5. Certificate Request (opcional): se a autenticação do cliente for necessária, o servidor solicita o certificado do cliente.
6. Server Hello Done: o servidor sinaliza que terminou sua parte do handshake.
7. Certificado do cliente (opcional): se solicitado, o cliente envia seu certificado.
8. Client Key Exchange: o cliente gera um pre-master secret, criptografa-o com a chave pública do servidor (obtida do certificado) e o envia ao servidor. Cliente e servidor então usam suas sequências aleatórias e esse pre-master secret para derivar uma chave de sessão simétrica comum.
9. Change Cipher Spec e Finished: cliente e servidor enviam mensagens "Change Cipher Spec", indicando que a comunicação subsequente será criptografada com a chave simétrica recém-negociada. Em seguida, enviam mensagens "Finished", criptografadas com a chave de sessão, para verificar que o handshake foi bem-sucedido e seguro.

Desse ponto em diante, todos os dados da aplicação (requisições e respostas HTTP) são criptografados e descriptografados usando a chave de sessão simétrica, garantindo comunicação eficiente e segura.

Servidores proxy e o desafio do HTTPS

Servidores proxy, por natureza, atuam como intermediários nas requisições de rede. Embora isso seja simples para tráfego HTTP não criptografado, o HTTPS apresenta um desafio fundamental: a criptografia foi projetada para ser ponta a ponta, diretamente entre o cliente e o servidor de destino. Um proxy no meio do caminho não consegue simplesmente ler ou modificar esse tráfego criptografado sem quebrar as garantias de segurança do HTTPS.

O paradoxo do "man-in-the-middle"

O paradoxo central entre HTTPS e proxies é que, para um proxy inspecionar conteúdo criptografado, ele precisa agir efetivamente como um "man-in-the-middle" (MITM). No entanto, um ataque MITM legítimo é exatamente o que o HTTPS foi projetado para impedir. Para que um proxy desempenhe esse papel sem disparar avisos de segurança, são necessários mecanismos e configurações de confiança específicos.

Tipos de proxy e tratamento do HTTPS

A forma como um proxy lida com tráfego HTTPS depende em grande parte de seu tipo e finalidade:

• Proxies diretos (forward): esses proxies são usados por clientes para acessar recursos externos. Para HTTPS, um forward proxy normalmente usa o método CONNECT para estabelecer um túnel TCP. O proxy não descriptografa o tráfego; ele apenas encaminha os bytes criptografados entre o cliente e o servidor de destino. Isso preserva a criptografia ponta a ponta. O GProxy opera principalmente como forward proxy, garantindo que seu tráfego criptografado permaneça privado e seguro.
• Proxies reversos: posicionados na frente de um ou mais servidores web, os proxies reversos interceptam as requisições do cliente antes que elas cheguem ao servidor de origem. Para HTTPS, os proxies reversos costumam realizar a "terminação TLS". Eles descriptografam o tráfego HTTPS de entrada, processam a requisição HTTP e, então, frequentemente recriptografam o tráfego antes de encaminhá-lo ao servidor de backend. Isso tira o processamento criptográfico do servidor de origem e permite recursos como balanceamento de carga, cache e Web Application Firewalls (WAFs).
• Proxies transparentes: esses proxies interceptam o tráfego sem exigir configuração explícita no cliente. Para HTTPS, os proxies transparentes enfrentam um desafio significativo. Para inspecionar tráfego HTTPS, eles precisam realizar um ataque MITM, gerando e assinando certificados dinamicamente para os sites de destino. Isso exige que o cliente confie no certificado de CA raiz do proxy transparente, o que os torna adequados principalmente para ambientes controlados, como redes corporativas.

O método CONNECT: a base para túneis seguros

O método CONNECT é o mecanismo padrão para proxies HTTP lidarem com protocolos não HTTP, incluindo o HTTPS. Quando um cliente quer estabelecer uma conexão HTTPS através de um forward proxy, ele envia ao proxy uma requisição HTTP CONNECT, especificando o host e a porta de destino (normalmente 443):

CONNECT www.example.com:443 HTTP/1.1
Host: www.example.com:443
Proxy-Connection: Keep-Alive
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/100.0.4896.88 Safari/537.36

Ao receber isso, o proxy tenta estabelecer uma conexão TCP direta com www.example.com na porta 443. Se der certo, o proxy responde com um status 200 OK:

HTTP/1.1 200 Connection established
Proxy-Agent: GProxy/1.0

Depois disso, o proxy simplesmente encaminha dados TCP brutos entre o cliente e o servidor de destino. Ele não inspeciona, não descriptografa nem modifica os dados dentro desse túnel. O handshake TLS e a troca subsequente de dados criptografados da aplicação ocorrem diretamente entre o cliente e o servidor de origem, com o proxy atuando apenas como retransmissor dos bytes criptografados. Isso garante que a conexão do cliente com o servidor de origem permaneça criptografada ponta a ponta e segura, um princípio central mantido por serviços como o GProxy.

Interceptação de HTTPS: técnicas e implicações

Embora o método CONNECT permita que proxies encaminhem tráfego HTTPS com segurança e sem interceptação, existem cenários em que descriptografar e inspecionar o tráfego HTTPS é necessário ou desejável. Essas técnicas quebram a criptografia ponta a ponta e têm implicações significativas de segurança e privacidade.

Terminação TLS/SSL no proxy

A terminação TLS é uma prática comum, especialmente com proxies reversos e balanceadores de carga. Nesse cenário, o proxy descriptografa o tráfego HTTPS que chega do cliente. Em seguida, processa a requisição HTTP (por exemplo, aplica regras de balanceamento de carga, filtra por meio de um WAF ou serve conteúdo em cache). Se a requisição precisar ser encaminhada a um servidor de backend, o proxy normalmente recriptografa a conexão com o backend, estabelecendo uma nova sessão TLS. Isso costuma ser chamado de "recriptografia" ou "SSL bridging".

Benefícios:

• Otimização de desempenho: tira dos servidores de backend a descriptografia TLS, que consome muita CPU, permitindo que se concentrem na lógica da aplicação.
• Gerenciamento centralizado de certificados: simplifica a implantação e a renovação de certificados, administrando-os em uma única camada de proxy.
• Segurança aprimorada: viabiliza inspeção profunda de pacotes (DPI) para Web Application Firewalls (WAFs), sistemas de detecção/prevenção de intrusão (IDS/IPS) e soluções de Data Loss Prevention (DLP) que protegem as aplicações de backend.
• Modificação de conteúdo: permite que os proxies alterem cabeçalhos HTTP, injetem conteúdo ou apliquem compressão antes de encaminhar ao backend.

Desvantagens:

• Mudança no modelo de confiança: o proxy passa a ser um componente confiável que enxerga o tráfego em texto claro. A segurança do próprio proxy torna-se prioritária.
• Maior complexidade: exige configuração cuidadosa de certificados e de parâmetros TLS no proxy.

Essa abordagem costuma ser usada quando o proxy faz parte da mesma infraestrutura confiável dos servidores de backend e o objetivo é melhorar a segurança e o desempenho do serviço web, e não interceptar o tráfego do cliente para vigilância.

Proxy man-in-the-middle (MITM) para inspeção

Quando um forward proxy precisa inspecionar o tráfego HTTPS dos clientes, ele deve realizar uma interceptação MITM completa. Essa técnica é frequentemente empregada em redes corporativas para monitoramento de segurança, filtragem de conteúdo ou conformidade. Veja como funciona:

1. O cliente tenta se conectar a um site HTTPS (por exemplo, https://bank.com) através do proxy MITM.
2. O proxy intercepta a requisição CONNECT do cliente. Em vez de simplesmente tunelar, o proxy estabelece sua própria conexão TLS com bank.com.
3. Ao mesmo tempo, o proxy gera na hora um novo certificado digital para bank.com. Esse certificado é assinado pela Autoridade Certificadora (CA) própria do proxy.
4. O proxy apresenta esse certificado recém-gerado ao cliente.
5. Para que o cliente confie nesse certificado e prossiga sem avisos de segurança, o sistema operacional ou o navegador do cliente precisa ter o certificado da CA personalizada do proxy instalado e explicitamente marcado como confiável.
6. Se o cliente confiar na CA do proxy, ele conclui o handshake TLS com o proxy.
7. Agora o cliente tem uma conexão TLS segura com o proxy, e o proxy tem uma conexão TLS segura com o servidor original. O proxy pode descriptografar o tráfego do cliente, inspecioná-lo, eventualmente modificá-lo e então recriptografá-lo antes de enviá-lo ao servidor, e vice-versa.

Casos de uso:

• Inspeção de segurança: detectar malware, tentativas de phishing ou exfiltração de dados dentro de tráfego criptografado.
• Filtragem de conteúdo: aplicar políticas de uso aceitável bloqueando o acesso a tipos específicos de conteúdo, mesmo por HTTPS.
• Data Loss Prevention (DLP): impedir que dados sensíveis (por exemplo, números de cartão de crédito, PII) saiam da rede em forma criptografada.
• Otimização de desempenho: armazenar em cache conteúdo criptografado (após a descriptografia) para entrega mais rápida a usuários seguintes.

Considerações éticas e de segurança: o proxy MITM levanta preocupações significativas de privacidade. Ele dá ao proxy visibilidade total de todas as comunicações criptografadas. Precisa ser implementado com controles rígidos e transparência, normalmente dentro da própria rede de uma organização e com consentimento do usuário ou política clara. O GProxy, como serviço focado em privacidade e anonimato do usuário, não realiza interceptação MITM do tráfego dos usuários.

SNI (Server Name Indication) e ESNI/ECH

SNI: Server Name Indication é uma extensão do TLS que permite ao cliente especificar o hostname que está tentando acessar durante o handshake TLS. Isso é essencial para servidores que hospedam vários sites HTTPS em um único endereço IP (por exemplo, example.com e anothersite.org no mesmo servidor). Sem SNI, o servidor não saberia qual certificado apresentar antes que a requisição HTTP propriamente dita (que contém o cabeçalho Host) fosse enviada. Para proxies, o SNI é valioso porque permite determinar o hostname de destino para fins de roteamento, mesmo antes de o handshake TLS ser concluído e sem descriptografar os dados da aplicação. Um proxy pode usar o SNI para direcionar o tráfego ao servidor upstream correto ou aplicar políticas com base no domínio de destino.

ESNI/ECH: o SNI criptografado (ESNI) e seu sucessor, o Encrypted Client Hello (ECH), são extensões TLS emergentes projetadas para criptografar o próprio campo SNI. O campo SNI, embora útil para proxies e redes de distribuição de conteúdo, é transmitido em texto puro durante o handshake TLS inicial. Isso significa que intermediários de rede (incluindo ISPs, governos ou mesmo proxies básicos) podem ver a qual site o usuário está tentando se conectar, mesmo que o conteúdo da comunicação esteja criptografado. O ESNI/ECH busca impedir esse vazamento criptografando a mensagem client hello, incluindo o SNI. A adoção ampla do ESNI/ECH impactará significativamente a análise de tráfego e a capacidade de filtragem de proxies que dependem do SNI em texto puro para roteamento ou aplicação básica de políticas, empurrando a internet para algo mais opaco aos intermediários. Os proxies terão de se adaptar a essa mudança, possivelmente recorrendo a endereços IP (que ainda podem ser observados) ou a inspeção mais profunda, se autorizada.

GProxy e operações HTTPS seguras

O GProxy foi projetado para oferecer serviços de proxy robustos e de alto desempenho que respeitam a integridade das conexões HTTPS, com foco especial na privacidade do usuário e na transmissão segura de dados.

Garantindo segurança ponta a ponta com o GProxy

Em sua essência, o GProxy opera como um forward proxy sem interceptação para tráfego HTTPS. Quando você roteia suas requisições HTTPS pelo GProxy, nossa infraestrutura viabiliza o método CONNECT, estabelecendo um túnel TCP seguro e opaco entre seu cliente e o servidor de destino. Isso significa:

• Criptografia ponta a ponta real: o handshake TLS ocorre diretamente entre seu cliente e o servidor web de destino. O GProxy não descriptografa seu tráfego.
• Confidencialidade dos dados: seus dados sensíveis, incluindo credenciais de login, informações financeiras e comunicações pessoais, permanecem criptografados durante todo o percurso pela rede GProxy, do seu dispositivo até o servidor de destino.
• Sem manipulação de certificados: o GProxy não gera nem reassina certificados. Você sempre verá o certificado legítimo do site de destino, o que garante confiança e evita ataques MITM do nosso lado.

Esse compromisso com a não interceptação é fundamental na proposta de valor do GProxy, oferecendo aos usuários a tranquilidade de que suas comunicações criptografadas permanecem privadas e seguras.

Recursos específicos do GProxy para HTTPS

• Infraestrutura de alto desempenho: a rede global de servidores do GProxy é otimizada para baixa latência e alta taxa de transferência. Isso garante que, mesmo com a sobrecarga de criptografia e descriptografia (feita pelo seu cliente e pelo servidor de destino), suas conexões HTTPS continuem rápidas e responsivas. Mantemos conexões robustas com os principais backbones da internet, minimizando o tempo de ida e volta em sessões criptografadas.
• Cobertura global de rede: com servidores proxy estrategicamente posicionados em vários continentes, o GProxy permite rotear seu tráfego HTTPS por diferentes localizações geográficas. Isso é valioso para casos de uso como:
  • Navegação anônima: mascarar seu IP real ao acessar sites HTTPS.
  • Coleta segura de dados: coletar dados publicamente disponíveis em sites HTTPS sem revelar seu IP de origem, mantendo a integridade dos dados coletados.
  • Desbloqueio geográfico: acessar conteúdo restrito por região em plataformas HTTPS, como serviços de streaming ou sites de notícias locais, mantendo uma conexão segura.
• Conectividade confiável: a infraestrutura do GProxy foi construída para estabilidade, garantindo disponibilidade consistente para suas conexões HTTPS seguras. Nossos engenheiros de rede monitoram e otimizam rotas continuamente para minimizar quedas de conexão e maximizar o uptime, o que é crítico em sessões seguras de longa duração.

Configurando aplicações para HTTPS com o GProxy

Integrar o GProxy às suas aplicações para tráfego HTTPS é simples. A maioria dos sistemas operacionais, navegadores e bibliotecas de programação modernos suporta configurações padrão de proxy HTTP tanto para HTTP quanto para HTTPS.

Configuração no navegador: Você pode configurar seu navegador (Chrome, Firefox, Edge, Safari) para usar um servidor GProxy em todo o tráfego, incluindo HTTPS. Normalmente, isso é feito nas configurações de rede do navegador ou nas configurações de proxy do sistema. Basta informar o endereço IP e a porta do GProxy.

Exemplo com cURL: Para operações em linha de comando, o cURL é amplamente usado. Para fazer uma requisição HTTPS através de um servidor GProxy:

curl -x http://your_gproxy_ip:port -U user:password https://www.google.com

Exemplo com a biblioteca Python Requests: A biblioteca requests do Python simplifica requisições HTTP/HTTPS e a configuração de proxy:

import requests

# Substitua pelos dados do seu GProxy
proxy_ip = "your_gproxy_ip"
proxy_port = "your_gproxy_port"
proxy_user = "your_gproxy_username"
proxy_password = "your_gproxy_password"

proxies = {
    "http": f"http://{proxy_user}:{proxy_password}@{proxy_ip}:{proxy_port}",
    "https": f"http://{proxy_user}:{proxy_password}@{proxy_ip}:{proxy_port}",
}

try:
    # Fazendo uma requisição HTTPS através do GProxy
    response = requests.get("https://httpbin.org/ip", proxies=proxies, timeout=10)
    response.raise_for_status() # Levanta uma exceção em caso de erro HTTP
    print(f"Successfully connected via GProxy. Your perceived IP: {response.json()['ip']}")
    
    # Exemplo de coleta segura de dados em um site HTTPS
    secure_page_response = requests.get("https://www.example.com", proxies=proxies, timeout=15)
    secure_page_response.raise_for_status()
    print(f"Fetched content from example.com (first 200 chars):\n{secure_page_response.text[:200]}...")

except requests.exceptions.RequestException as e:
    print(f"An error occurred: {e}")

Este exemplo em Python mostra como configurar a biblioteca requests para usar o GProxy em conexões HTTP e HTTPS, garantindo que até suas interações programáticas se beneficiem da segurança e do anonimato oferecidos pelo GProxy.

Considerações avançadas e tendências futuras

O cenário de segurança na internet e de operações de proxy está em constante evolução. Diversas considerações avançadas e tendências emergentes continuarão a moldar a forma como o HTTPS é tratado pelos proxies.

HTTP/3 e QUIC

O HTTP/3 é a mais recente revisão importante do protocolo HTTP, construída sobre o QUIC (Quick UDP Internet Connections) em vez do TCP. O QUIC é um novo protocolo de camada de transporte que roda sobre UDP, projetado para reduzir a latência e melhorar o desempenho, especialmente em redes com perda de pacotes. Para proxies tradicionais, que costumam operar na camada TCP, o HTTP/3 e o QUIC trazem novos desafios:

• Baseado em UDP: o QUIC usa UDP (User Datagram Protocol), que é sem conexão, ao contrário do TCP. Isso muda de forma fundamental como os proxies interceptam e encaminham o tráfego.
• Handshake criptografado: o QUIC criptografa seu handshake por padrão, dificultando que proxies inspecionem parâmetros iniciais da conexão (como o SNI) em comparação com TLS sobre TCP.
• Migração de conexão: o QUIC suporta migração de conexão entre endereços IP e portas, o que pode complicar o rastreamento de sessões pelos proxies.

Os proxies precisarão se adaptar, seja tunelando o tráfego QUIC (de forma semelhante ao tunelamento TCP para HTTPS com CONNECT), seja implementando capacidades de proxy compatíveis com QUIC. Isso pode envolver proxies atuando como endpoints QUIC, terminando conexões QUIC e estabelecendo novas conexões upstream, de modo semelhante à terminação TLS para HTTP/2.

Certificate pinning

O certificate pinning é um mecanismo de segurança em que uma aplicação ou navegador memoriza, ou "fixa" (pins), a chave pública ou o certificado esperado de um servidor específico. Quando o cliente se conecta depois a esse servidor, ele verifica se o certificado do servidor corresponde ao que foi fixado. Se o certificado apresentado pelo servidor (ou por um proxy MITM) não corresponder ao valor fixado, a conexão é abortada, mesmo que o certificado seja válido e assinado por uma CA confiável.

Impacto sobre os proxies: o certificate pinning consegue efetivamente contornar ou detectar o proxy MITM. Se uma aplicação fixou o certificado de um servidor, um proxy MITM que tente interceptar a conexão apresentando seu próprio certificado gerado dinamicamente (mesmo que assinado por uma CA corporativa confiável) será detectado, e a conexão falhará. Esse é um recurso de segurança comum em aplicativos de banco para celular e em outras aplicações de alta segurança, o que os torna imunes à inspeção MITM corporativa padrão.

Criptografia resistente a quantum

O surgimento de computadores quânticos poderosos representa uma ameaça teórica aos atuais algoritmos de criptografia de chave pública, como RSA e criptografia de curvas elípticas (ECC), que são a base do HTTPS. Embora computadores quânticos práticos capazes de quebrar esses algoritmos ainda estejam a anos de distância, pesquisadores desenvolvem ativamente algoritmos de criptografia "resistente a quantum" ou "pós-quântica" (PQC).

O futuro do HTTPS: o IETF e o NIST trabalham na padronização de novos algoritmos PQC. Nos próximos anos, as implementações de HTTPS provavelmente começarão a integrar esses novos algoritmos para preparar as comunicações seguras para o futuro. Essa transição exigirá atualizações em todo o ecossistema da internet, incluindo navegadores, servidores e, de modo crucial, proxies. Proxies que fazem terminação TLS ou inspeção MITM precisarão suportar esses novos algoritmos para manter compatibilidade e segurança.

Tabela comparativa: cenários de proxy com HTTPS

Conclusão

O HTTPS é mais do que um recurso de segurança; é um pilar fundamental da internet moderna, garantindo a confidencialidade, a integridade e a autenticidade das comunicações on-line. Para serviços de proxy, o HTTPS apresenta uma dicotomia interessante: pode ser tratado como um túnel opaco e seguro para privacidade e anonimato, ou pode ser interceptado estrategicamente para atender a requisitos avançados de segurança, desempenho ou gestão de conteúdo.

A abordagem do GProxy para o HTTPS prioriza a segurança e a privacidade ponta a ponta do usuário. Operando como um forward proxy sem interceptação que utiliza o método CONNECT, o GProxy garante que seus dados criptografados permaneçam invioláveis entre o seu cliente e o servidor de destino. Esse compromisso permite que nossos usuários realizem com confiança coleta segura de dados, navegação anônima e desbloqueio geográfico, sabendo que suas informações sensíveis estão protegidas contra inspeção por intermediários.

À medida que a internet evolui com tecnologias como HTTP/3, ESNI/ECH e criptografia pós-quântica, o papel dos proxies no tratamento do HTTPS continuará a se adaptar. O GProxy segue dedicado a se manter na vanguarda desses avanços, oferecendo soluções de proxy robustas, seguras e de alto desempenho que capacitam os usuários sem abrir mão das garantias críticas de segurança do HTTPS.