HTTPS CONNECT

O método CONNECT do HTTP permite que um cliente instrua um proxy a estabelecer um túnel TCP direto até um host e porta de destino específicos, viabilizando principalmente o encapsulamento seguro de tráfego não HTTP, como HTTPS, através do proxy. Esse mecanismo é essencial para que comunicações criptografadas atravessem um proxy HTTP sem que o proxy descriptografe o tráfego.

Entendendo o tunelamento de proxy com CONNECT

Quando um cliente precisa acessar um recurso via HTTPS, a comunicação deve ser criptografada de ponta a ponta entre o cliente e o servidor de origem. Um proxy HTTP padrão, que normalmente opera lendo e encaminhando requisições HTTP (GET, POST etc.), não consegue lidar diretamente com tráfego HTTPS, pois não pode descriptografar os dados sem quebrar a conexão TLS (Transport Layer Security). O método CONNECT resolve isso transformando o proxy em um simples relay TCP durante toda a conexão.

O desafio do tráfego criptografado para proxies

O HTTPS depende de um handshake TLS iniciado pelo cliente diretamente com o servidor de origem. Esse handshake envolve a troca de chaves criptográficas e certificados, estabelecendo um canal seguro e criptografado. Se um proxy tentasse interceptar e descriptografar esse tráfego, ele precisaria apresentar seu próprio certificado ao cliente, que não corresponderia ao certificado esperado do servidor de origem, resultando em avisos de segurança ou falhas de conexão, a menos que configurações específicas de confiança estejam em vigor.

O método CONNECT contorna esse problema instruindo o proxy a abrir uma conexão TCP bruta até o destino especificado. Uma vez estabelecida a conexão, o proxy deixa de analisar requisições HTTP e simplesmente encaminha todos os fluxos de bytes brutos subsequentes entre o cliente e o servidor de destino, criando efetivamente um túnel cego.

Como o método CONNECT funciona

O processo de estabelecer um túnel HTTPS via método CONNECT envolve um handshake específico entre cliente e proxy, seguido pelo handshake TLS direto do cliente com o servidor de origem através do túnel estabelecido.

1. O cliente envia a requisição CONNECT ao proxy:
   O cliente inicia o processo enviando uma requisição HTTP CONNECT ao proxy. Essa requisição especifica o host e a porta de destino aos quais o cliente deseja se conectar. A porta para HTTPS costuma ser a 443.

   http CONNECT www.example.com:443 HTTP/1.1 Host: www.example.com:443 Proxy-Connection: Keep-Alive User-Agent: MyApp/1.0
   Essa requisição sinaliza ao proxy: "Estabeleça uma conexão TCP bruta com www.example.com na porta 443. Uma vez conectado, retransmita todos os dados subsequentes entre mim e esse servidor, sem inspeção."

2. O proxy estabelece a conexão e responde:

   • O proxy recebe a requisição CONNECT e tenta estabelecer uma conexão TCP direta com www.example.com na porta 443.
   • Se a conexão for estabelecida com sucesso, o proxy envia uma resposta HTTP 200 OK de volta ao cliente.

   http HTTP/1.1 200 Connection established Proxy-Agent: MyProxyService/1.0
   Essa resposta 200 OK confirma ao cliente que o túnel TCP está ativo.

3. Handshake TLS e comunicação criptografada:

   • Ao receber o 200 OK, o cliente para de enviar requisições HTTP ao proxy. Em vez disso, passa a enviar mensagens brutas de handshake TLS diretamente para www.example.com através do túnel de proxy estabelecido.
   • O proxy, atuando puramente como relay, encaminha essas mensagens TLS sem tentar interpretá-las ou modificá-las.
   • Quando o handshake TLS é concluído com sucesso, um canal criptografado de ponta a ponta é estabelecido entre o cliente e www.example.com. Todos os dados de aplicação subsequentes (por exemplo, requisições e respostas HTTP sobre HTTPS) trafegam com segurança por esse túnel, completamente opacos para o proxy.

Vantagens do tunelamento com CONNECT

• Criptografia de ponta a ponta: o principal benefício é a preservação da criptografia de ponta a ponta. O proxy nunca vê o conteúdo em texto claro da comunicação, garantindo confidencialidade e integridade dos dados entre o cliente e o servidor de origem.
• Independência de protocolo: embora seja usado principalmente para HTTPS, o método CONNECT pode tunelar qualquer protocolo baseado em TCP. Como o proxy apenas retransmite bytes brutos depois que o túnel é criado, ele não precisa entender o protocolo encapsulado.
• Passagem por firewalls: o CONNECT permite que clientes atrás de firewalls restritivos acessem serviços externos (por exemplo, sites seguros) canalizando todo o tráfego por uma única porta de proxy permitida (normalmente 80 ou 443).
• Privacidade: como o proxy não inspeciona os dados tunelados, o conteúdo da comunicação permanece privado entre o cliente e o destino.

Considerações de segurança

CONNECT padrão vs. proxies de interceptação SSL/TLS

Um proxy CONNECT padrão, como descrito, funciona como um relay cego. Ele não executa um ataque Man-in-the-Middle (MITM); não descriptografa, não inspeciona nem recriptografa o tráfego HTTPS. O navegador do cliente verifica o certificado do servidor de origem diretamente, garantindo a autenticidade da conexão.

Em contraste, algumas soluções especializadas, muitas vezes chamadas de "proxies de inspeção SSL/TLS" ou "proxies interceptadores", de fato executam um ataque MITM. Esses proxies são projetados para descriptografar e inspecionar tráfego criptografado com finalidades como filtragem de conteúdo, prevenção contra perda de dados (DLP) ou detecção de ameaças. Sua operação envolve:

1. Interceptar a requisição CONNECT do cliente.
2. Estabelecer sua própria conexão TLS com o servidor de origem.
3. Gerar dinamicamente um novo certificado SSL para o domínio solicitado, assinado por uma Autoridade Certificadora (CA) raiz personalizada, controlada pelo dono do proxy.
4. Apresentar esse certificado gerado pelo proxy ao cliente.
5. Se o cliente estiver configurado para confiar na CA raiz personalizada do proxy (normalmente instalando-a no repositório de confiança do sistema operacional), ele aceita o certificado e estabelece uma conexão TLS com o proxy.
6. O proxy então mantém, na prática, duas conexões TLS separadas: uma com o cliente e outra com o servidor de origem. Isso permite descriptografar o tráfego vindo do cliente, inspecioná-lo e recriptografá-lo antes de encaminhá-lo à origem, e vice-versa.

Sem que o cliente confie explicitamente no certificado da CA raiz do proxy, o navegador exibiria avisos graves de certificado, indicando um possível risco de segurança. Nosso serviço opera como um proxy CONNECT padrão, mantendo a integridade da criptografia de ponta a ponta, sem interceptação.

Configuração de proxy e CONNECT

Quando uma aplicação cliente ou um navegador é configurado para usar um proxy HTTP, ele determina automaticamente se deve usar um método HTTP padrão (como GET ou POST, para HTTP não criptografado) ou o método CONNECT (para HTTPS criptografado), com base no esquema da URL de destino.

Por exemplo, se um navegador estiver configurado para usar proxy.example.com:8080:
* Uma requisição para http://www.unencrypted.com resulta no envio de GET http://www.unencrypted.com HTTP/1.1 para proxy.example.com:8080.
* Uma requisição para https://www.encrypted.com resulta no envio de CONNECT www.encrypted.com:443 HTTP/1.1 para proxy.example.com:8080.

Comparação: proxy HTTP vs. proxy HTTPS (via CONNECT)

Implicações práticas para os usuários

Usar um serviço de proxy que suporte o método CONNECT garante que seu tráfego HTTPS permaneça seguro e privado entre seu cliente e o servidor de destino. Nosso serviço foi projetado para tunelar suas comunicações criptografadas sem interceptação ou modificação, preservando a criptografia de ponta a ponta.

• Compatibilidade com firewall: ao configurar um cliente para usar um proxy, verifique se as regras do firewall local permitem conexões de saída para o endereço IP e a porta do servidor proxy (por exemplo, proxy.service.com:8080). O proxy então gerencia a conexão até o destino final.
• Desempenho: a sobrecarga do tunelamento com CONNECT é mínima, envolvendo basicamente a requisição e a resposta iniciais de CONNECT. Uma vez estabelecido o túnel, o desempenho da transferência de dados depende principalmente da latência e da banda entre o cliente, o proxy e o servidor de origem.
• Solução de problemas: se surgirem problemas com sites HTTPS ao usar o proxy, verifique o seguinte:
  • Configuração correta de host e porta do proxy na aplicação cliente ou no navegador.
  • Conectividade de rede bem-sucedida do seu cliente até o servidor proxy.
  • Que o servidor proxy não esteja configurado para bloquear o acesso ao host ou à porta de destino específicos.