Proxies HTTP e HTTPS

Um proxy HTTP aceita solicitações web do seu navegador ou aplicativo e se conecta ao destino em seu nome. Ele pode transportar tráfego HTTP comum e, com suporte ao método CONNECT, tráfego HTTPS criptografado. Um proxy HTTPS acrescenta criptografia à conexão entre seu aplicativo e o próprio proxy.

São duas escolhas separadas: como seu aplicativo chega ao proxy e como ele se comunica com o site por esse proxy. Entender as duas ajuda a selecionar as configurações corretas de conexão. A escolha mais ampla entre protocolos de proxy é abordada em Proxies SOCKS ou HTTP.

O que um proxy HTTP faz com uma solicitação web

Suponha que um script de monitoramento solicite http://example.com/catalog. Em vez de abrir uma conexão com o site, ele se conecta ao proxy configurado. Com HTTP/1.1, envia a URL de destino completa na solicitação para que o proxy saiba qual servidor e página contatar. O proxy encaminha a solicitação e retorna a resposta do site ao script.

Nesse modo, o proxy processa mensagens HTTP. Ele pode ler o método, como GET ou POST, o endereço solicitado, os cabeçalhos e quaisquer dados enviados. Um software configurado para essa finalidade pode aplicar regras de acesso, registrar solicitações ou armazenar respostas elegíveis em cache. O cache é uma função opcional regida pelas regras de cache da resposta; comprar acesso a um proxy HTTP não significa que todas as páginas serão armazenadas em cache.

O site recebe a conexão de rede do IP de saída do proxy. O termo HTTP não informa de onde vem esse IP nem por quanto tempo ele permanece atribuído. O mesmo protocolo de conexão pode ser oferecido com endereços de datacenter, ISP, residenciais ou móveis, usando IPs fixos ou um pool rotativo.

Como um proxy HTTP abre um site HTTPS

Um site HTTPS usa TLS para proteger a troca entre o aplicativo e o site. Para transportar essa troca, um proxy HTTP primeiro cria um túnel. Para uma solicitação a https://example.com/catalog, a sequência é:

1. O aplicativo se conecta ao proxy e pede que ele abra um túnel até example.com:443, usando o método CONNECT. A solicitação indica o host e a porta de destino, sem o caminho da página.
2. O proxy verifica se o acesso e o destino solicitado são permitidos, incluindo qualquer autenticação de proxy necessária. Ele abre uma conexão com o destino e confirma que o túnel está pronto.
3. O aplicativo realiza um handshake TLS com o site pelo túnel e verifica o certificado do site.
4. O aplicativo envia sua solicitação web dentro dessa conexão TLS. O proxy retransmite os bytes criptografados nas duas direções.

O proxy não precisa ler a página para entregá-la. O aplicativo e o site continuam sendo as extremidades da conexão TLS do site. CONNECT fornece o túnel; TLS fornece criptografia e protege a troca contra alterações não detectadas.

É por isso que um proxy HTTP consegue abrir um site HTTPS mesmo quando o endereço do proxy começa com http://. A proteção HTTPS do site funciona dentro do túnel. Ela não depende da existência de TLS entre o aplicativo e o proxy.

O que um proxy HTTPS acrescenta

Com um proxy HTTPS, o aplicativo primeiro estabelece TLS com o proxy e verifica o certificado dele. Depois, envia suas solicitações HTTP ou sua solicitação CONNECT de túnel dentro dessa conexão protegida. Um observador da rede entre o aplicativo e o proxy não consegue ler essas solicitações.

Para um destino HTTPS, o aplicativo mantém duas conexões TLS separadas: uma com o proxy e outra com o site pelo túnel. O proxy remove a proteção externa destinada a ele, mas os dados do site dentro dela continuam criptografados. Ele encaminha esses bytes ao site, que pode descriptografá-los. Para um destino HTTP, não existe conexão TLS interna: apenas a conexão até o proxy é protegida.

Essa comparação descreve o encaminhamento comum de proxy com verificações de certificado ativadas, sem inspeção HTTPS nem uma VPN separada. Criptografar a conexão com um proxy não transforma um site HTTP em HTTPS.

O que o proxy e o site podem ver

Para um destino HTTPS, um proxy de encaminhamento não consegue ler o caminho da página, os parâmetros de consulta, os cookies, os dados de formulário nem o conteúdo retornado dentro da conexão TLS. Ele ainda conhece o IP do cliente que se conectou a ele, o host e a porta de destino solicitados em CONNECT, além dos horários e do volume de tráfego. O TLS até o proxy mantém CONNECT privado em relação a observadores nessa parte da rede, mas não em relação ao proxy que precisa executá-lo.

As credenciais do proxy são enviadas separadamente do login de um site. A autenticação Basic do proxy codifica o nome de usuário e a senha em Base64, que pode ser decodificado sem uma chave secreta. Em uma conexão de proxy HTTP simples, isso não os protege de um observador da rede. A conexão HTTPS do site começa dentro do túnel e não abrange o login anterior do proxy. O TLS até o proxy protege esse login em trânsito.

Na outra extremidade, o site recebe tráfego do IP de saída e lê as solicitações destinadas a ele. Pode reconhecer uma conta, um cookie de sessão ou outras informações que o aplicativo envia. Escolher um proxy HTTPS não remove esses identificadores nem melhora automaticamente a aceitação do IP de saída pelo site.

A inspeção HTTPS é uma configuração diferente usada em algumas redes gerenciadas e ferramentas de depuração. O aplicativo confia em uma autoridade certificadora controlada pelo proxy de inspeção, que pode então ler o tráfego enquanto mantém conexões TLS separadas de cada lado. O encaminhamento normal por CONNECT não exige instalar esse tipo de certificado. Confiar no certificado do próprio servidor do proxy HTTPS é diferente de permitir que ele se passe por sites.

Como ler as configurações de conexão

Uma configuração de proxy precisa de um endereço, uma porta, um protocolo de conexão e qualquer autenticação necessária. O protocolo na URL do proxy se aplica ao proxy. O protocolo na URL de destino se aplica ao site.

Estes comandos curl solicitam o mesmo site HTTPS por duas conexões de proxy diferentes. Substitua o nome de host e a porta do proxy pelos valores fornecidos para o método de conexão escolhido:

curl --proxy http://proxy.example:8080 https://example.com/
curl --proxy https://proxy.example:8443 https://example.com/

O primeiro comando se conecta ao proxy por HTTP e depois cria CONNECT e TLS até o site. O segundo cria primeiro TLS até o proxy HTTPS e depois transporta por ele a conexão TLS separada do site. Nos dois casos, forneça também a autenticação exigida pelo serviço de proxy.

Simplesmente mudar http:// para https:// não transforma uma porta somente HTTP em um ponto de conexão TLS. Se o serviço fornece um nome de host para acesso HTTPS, use esse nome: substituí-lo por um IP pode causar uma divergência com o nome no certificado.

Os rótulos nos aplicativos exigem a mesma leitura cuidadosa. Um campo chamado “proxy HTTPS” pode selecionar o proxy para sites HTTPS e ainda se conectar a ele por HTTP simples. No curl, a variável HTTPS_PROXY também seleciona um proxy para destinos HTTPS; seu valor pode começar corretamente com http://. O rótulo informa quais solicitações usam a configuração, enquanto o esquema do proxy informa como a conexão é feita.

DNS e o tráfego que passa pelo proxy

Quando um cliente HTTP fornece um nome de host de destino, o proxy normalmente consulta seu IP e se conecta a ele. O cliente faz uma consulta separada se precisar do nome de host do próprio proxy para alcançá-lo. Um navegador também pode emitir consultas DNS para previsão ou outros recursos. Essas são consultas separadas; configurar um proxy web não encaminha todas as solicitações DNS por ele.

A configuração se aplica ao tráfego que o aplicativo realmente envia ao proxy. Outro programa pode continuar se conectando diretamente, e uma lista de exceções pode contornar o proxy para sites selecionados. Por exemplo, encaminhar um script de API por um proxy não muda a rota usada por um navegador sem relação com ele. Verifique o endereço de saída no aplicativo e na configuração que executarão a tarefa.

HTTP/2 até o site e HTTP/2 até o proxy

HTTP/2 permite que várias trocas compartilhem uma conexão usando fluxos separados. Com um proxy, importa qual conexão oferece suporte a isso. Um aplicativo pode negociar HTTP/2 com um site dentro de um túnel criado usando HTTP/1.1 CONNECT. O proxy retransmite os bytes criptografados e não precisa entender as mensagens HTTP/2 do site.

HTTP/2 entre o aplicativo e o proxy é um recurso separado. Cada túnel CONNECT usa seu próprio fluxo HTTP/2; assim, vários túneis podem compartilhar uma conexão com o proxy. Por exemplo, túneis para dois sites diferentes podem usar essa conexão enquanto mantêm conexões de destino e sessões TLS dos sites separadas. Isso reduz a necessidade de conexões adicionais entre cliente e proxy; não permite ao proxy ler as solicitações criptografadas dos sites.

Os dois lados devem oferecer suporte ao modo escolhido. HTTPS, por si só, não especifica HTTP/2: um proxy HTTPS pode usar HTTP/1.1. O desempenho também depende do cliente, da rota de rede, da carga do servidor e da reutilização de conexões. Um rótulo HTTP/2 não garante aumento de velocidade para todas as tarefas.

Um túnel CONNECT comum também pode transportar outros protocolos baseados em TCP se o aplicativo e o proxy os permitirem, embora as portas de destino possam ser restritas. Ele não retransmite UDP. HTTP/3 usa QUIC sobre UDP; por isso, não pode passar por esse túnel TCP da mesma forma. O encaminhamento UDP baseado em HTTP usa mecanismos adicionais, como CONNECT-UDP, e exige implementações compatíveis. O suporte apenas a HTTPS ou HTTP/2 não comprova esse suporte.

Onde o acesso por proxy HTTP e HTTPS é útil

Para navegação e testes de sites, um proxy HTTP com CONNECT fornece um método de conexão para destinos HTTP e HTTPS. Uma equipe pode usá-lo para visualizar um site a partir da rede do proxy, mantendo o navegador responsável pela renderização das páginas, pelos cookies e pelos logins nos sites.

Para rastreadores, clientes de API e monitores programados, um cliente HTTP pode enviar solicitações por um IP de saída escolhido enquanto mantém as URLs de destino inalteradas. O aplicativo continua preparando as solicitações e processando as respostas. Dentro de um túnel HTTPS, o proxy transporta essa troca sem precisar interpretar cada página ou chamada de API.

Um proxy HTTPS protegido por TLS é útil quando a conexão até o proxy também precisa de proteção, incluindo o login do proxy e as solicitações de destino. Isso importa quando essa conexão atravessa uma rede que você não controla. O cliente deve oferecer suporte a TLS até o próprio proxy; apenas conseguir abrir sites HTTPS não é suficiente.

Como interpretar erros de conexão

Uma falha pode acontecer ao alcançar o proxy, abrir o túnel ou se comunicar com o site. A etapa informa mais do que o código de erro sozinho.

Um túnel e um handshake TLS concluídos mostram que o caminho da conexão funciona. Eles não garantem que o site aceitará uma conta, um IP de saída ou uma solicitação específica. Portanto, uma verificação de login, CAPTCHA ou limite de solicitações pode exigir atenção no site ou no aplicativo mesmo quando o proxy está funcionando.