Quando um proxy passa a fazer o parsing do HTTP, em vez de só repassar bytes, ele vira outro tipo de ferramenta. Ele consegue rotear uma requisição pela URL ou pelo header (cabeçalho) Host, incluir ou remover headers, aplicar políticas com base no conteúdo real da requisição, guardar respostas em cache e reescrever o que passa por ele. É justamente para isso que vale pagar o custo do parsing na camada 7, um custo que o proxy TCP não tem. Mas "proxy HTTP" abrange implantações muito diferentes entre si, e duas perguntas independentes definem qual delas você tem na frente.

Eixo um: forward ou reverse

Um forward proxy trabalha para os clientes. Ele fica na borda da rede dos clientes e intermedeia as requisições que saem para a internet. A organização que o opera quer controlar, registrar, filtrar ou proteger aquilo que os seus próprios usuários acessam: filtragem web, varredura de malware, (data loss prevention) e registro de acessos, tudo isso acontece aqui. O conjunto de destinos é aberto (qualquer lugar da internet), e o conjunto de clientes é conhecido (os usuários da organização). O web gateway corporativo é o forward proxy clássico.

Um reverse proxy trabalha para os servidores. Ele fica na frente de um conjunto de aplicações web e intermedeia as requisições que chegam da internet até elas. A organização que o opera é dona dos servidores e quer protegê-los, distribuir a carga entre eles e tirar trabalho das costas deles: terminação de TLS, load balancing, cache, um (web application firewall) e roteamento de requisições, tudo isso acontece aqui. Agora o conjunto de clientes é aberto (qualquer um na internet), e o conjunto de destinos é conhecido (as aplicações da organização). Um load balancer (balanceador de carga) ou um na frente de um farm de servidores web é o reverse proxy clássico.

A mecânica é parecida, mas a direção da confiança é oposta, e isso muda tudo: como o proxy é configurado, que certificado ele apresenta e o que ele está tentando fazer. O mesmo equipamento físico pode fazer os dois papéis, para tráfegos diferentes, e é por isso que vale manter os dois modelos mentais bem separados.

Eixo dois: explícito ou transparente

Este eixo faz uma pergunta mais simples: o cliente sabe que o proxy está ali?

Um proxy explícito é aquele que o cliente usa porque foi configurado de propósito para isso. O navegador ou o sistema operacional tem um endereço e uma porta de proxy definidos (manualmente, por um arquivo ou pela descoberta automática do ) e envia as requisições ao proxy de forma intencional. No HTTP em texto claro, a requisição a um proxy explícito é visivelmente diferente: o cliente coloca a URL absoluta completa na request line (a linha de requisição), GET http://example.com/path HTTP/1.1, e não só o caminho, porque está pedindo ao proxy que vá buscar aquela URL. No HTTPS, o cliente não pode mandar a requisição em texto claro, então usa o método CONNECT: pede ao proxy que abra um túnel bruto até example.com:443, o proxy responde 200 Connection Established, e aí o cliente faz o handshake TLS normal através desse túnel. Um proxy explícito simples, que só faz CONNECT, é na prática um túnel de camada 4 para o HTTPS; para enxergar dentro desse túnel, o proxy precisa também interceptar o TLS, que é o tema do artigo sobre SSL forward proxy.

Um proxy transparente (também chamado de proxy inline ou proxy de interceptação) é aquele que o cliente não sabe que existe. Quem desvia o tráfego até ele é a rede: por roteamento, por policy-based routing, por um redirecionamento (Web Cache Communication Protocol) ou porque ele está inline no caminho; e o cliente acredita que está falando direto com o servidor de origem. A requisição parece totalmente normal (GET /path HTTP/1.1 com um header Host), porque, do lado do cliente, não está acontecendo nada de especial. A implantação transparente é cômoda porque não exige configuração no cliente, mas é também por isso que interceptar HTTPS de forma transparente causa tanto transtorno: o cliente nunca aceitou um proxy, então um proxy que de repente apresenta o próprio certificado tem toda a cara de um ataque, e defesas como o certificate pinning e o (HTTP Strict Transport Security) foram projetadas justamente para rejeitá-lo.

Os headers que registram a passagem por um proxy

Um reverse proxy que abre uma nova conexão até o backend esconde dele o endereço do cliente. É o mesmo problema de camada 4 descrito no artigo sobre proxy TCP, mas na camada 7 existe uma solução padrão. O proxy acrescenta um header X-Forwarded-For com o IP original do cliente (e vai somando valores a ele quando há vários proxies em cadeia), além de headers que o acompanham, como o X-Forwarded-Proto (se a conexão do cliente era HTTP ou HTTPS) e o X-Forwarded-Host. O equivalente moderno e padronizado é um header único, o Forwarded ( 7239), que leva as mesmas informações num só campo estruturado. Já o forward proxy, por convenção, acrescenta um header Via com o próprio nome, e assim a resposta carrega um registro visível dos proxies por onde passou.

Muita coisa depende desses headers, e eles precisam ser tratados com cuidado. Um backend que confia cegamente no X-Forwarded-For pode ser enganado por um cliente que preenche esse header por conta própria. Por isso, no hop voltado para o cliente (o primeiro proxy da cadeia), o proxy deve sobrescrever o header, e não apenas acrescentar um valor a ele; e o backend só deve confiar no header quando ele vem de endereços de proxy conhecidos. Essa é uma fonte comum de bugs de IP spoofing e de controle de acesso, e vale conferir sempre que alguma decisão do tipo "quem é o cliente" for tomada atrás de um proxy.

Os dois eixos juntos

Como os dois eixos são independentes, as quatro combinações existem e são usadas. O forward proxy explícito é o web gateway corporativo configurado nos clientes. O forward proxy transparente é um gateway inline que intercepta o tráfego de saída sem nenhuma configuração no cliente. O reverse proxy é quase sempre transparente do ponto de vista do cliente (o cliente só acessa um site e não sabe que há um proxy na frente dele), e só dá para chamá-lo de "explícito" no sentido estrito de que o DNS aponta o hostname para ele. Quando você topar com um proxy, nomear os dois eixos (para qual lado ele trabalha e se o cliente sabe que ele existe) já diz quase tudo o que você precisa saber sobre como ele se comporta.