Hoje, a maior parte do tráfego que sai de uma organização é criptografada com TLS, o que é bom para a privacidade e ruim para a equipe de segurança, que precisa ver o que os usuários estão enviando e recebendo. O malware esconde o seu tráfego de comando e controle dentro do HTTPS, e a exfiltração de dados usa os mesmos canais criptografados do trabalho legítimo. Um forward proxy que só faz túnel do HTTPS (pelo método CONNECT) consegue registrar o hostname de destino, mas não enxerga o que vai dentro. Para inspecionar o conteúdo, o proxy precisa descriptografá-lo, e descriptografar uma sessão feita para ser confidencial de ponta a ponta significa virar, de propósito e com autorização, um (alguém no meio da conversa). É isso que um SSL forward proxy faz.
Origens: o ponto de inspeção ficou cego
A inspeção de conteúdo nasceu numa época em que o tráfego era legível. Nos anos 1990, um proxy conseguia ler a URL, o header (o cabeçalho) e o corpo da mensagem porque quase nada era criptografado, e uma indústria inteira de filtragem web, varredura antivírus e prevenção de vazamento de dados foi construída sobre essa premissa.
Depois, a criptografia virou o padrão. Não foi uma decisão, foram três, e cada uma tirou mais visibilidade que a anterior: as autoridades certificadoras passaram a emitir certificados de graça a partir de 2015, os navegadores começaram a marcar o HTTP puro como inseguro, e o TLS 1.3 passou a criptografar a maior parte do handshake (o aperto de mão), inclusive o certificado. O tráfego que antes ficava aberto para qualquer equipamento no caminho ficou opaco, e a indústria de inspeção ficou com duas opções: perder a visibilidade ou terminar a sessão.
O SSL forward proxy é a segunda opção, e vale dizer claramente o que ele é: uma máquina no meio do caminho (machine-in-the-middle), deliberada e autorizada. A técnica é idêntica à do ataque; só a posse das chaves e o consentimento da organização fazem dela outra coisa.
Como funciona, e a peça que muita gente esquece
A mecânica se resume a duas sessões e um certificado forjado. O proxy termina a sessão TLS do cliente, apresentando um certificado que ele mesmo emite para o hostname de destino, e abre a sua própria sessão TLS até o servidor real. Entre as duas sessões, ele tem o tráfego em texto claro.
Para o cliente não reclamar, a emissora do proxy precisa estar instalada como confiável em todos os dispositivos. É essa peça que define o desenho inteiro, e ela é um compromisso maior do que parece. A organização não está acrescentando um certificado; está acrescentando uma autoridade capaz de emitir um certificado válido para qualquer nome da internet, e instalando essa autoridade em cada notebook e cada celular que administra. Quem controlar essa chave privada consegue se passar por qualquer destino diante desses dispositivos.
Daí vêm duas consequências, e as duas são estruturais, não operacionais.
O proxy tem tudo em texto claro. Sessões de banco, portais de saúde, e-mail pessoal. O equipamento passa a ver o que nada mais na rede conseguia ver, e isso faz dele o alvo mais valioso do parque e o equipamento cujos logs guardam o material mais sensível.
O cliente para de validar a internet e passa a validar você. Depois da interceptação, o certificado que o navegador confere é o seu. Se o proxy for frouxo na validação do certificado upstream (o do servidor real), aceitando um certificado vencido, autoassinado, com o nome errado ou revogado, o cliente não tem como saber, porque nunca vê esse certificado. Um equipamento de interceptação frouxo do lado upstream rebaixou a segurança de todos os usuários atrás dele, e continua mostrando um cadeado para eles.
A mecânica: duas sessões e um certificado forjado
Vamos dividir a interceptação em passos. O navegador de um usuário tenta acessar https://example.com. O forward proxy, instalado inline ou configurado como proxy do navegador, intercepta a conexão. Aí ele faz duas coisas ao mesmo tempo:
Primeiro, ele age como cliente do servidor real: abre a sua própria sessão TLS de saída até example.com, valida o certificado verdadeiro do servidor contra o seu trust store (o repositório de certificados confiáveis), como qualquer cliente faria, e estabelece uma sessão criptografada com a origem. É assim que o proxy vê a identidade real do servidor e obtém o conteúdo de verdade.
Segundo, ele age como servidor para o usuário: não pode apresentar o certificado real de example.com, porque não tem a chave privada de example.com. Em vez disso, gera na hora um certificado novo para example.com e o assina com a sua própria autoridade certificadora. Normalmente ele copia os campos de identidade do certificado real (o subject e os subject-alternative-names que acabou de ver na conexão de saída) para o certificado forjado, para que o nome bata com o que o usuário pediu. O navegador do usuário recebe esse certificado recém-emitido, confere o certificado e (este é o ponto crucial) precisa decidir se confia nele.
Agora o proxy controla as duas sessões. Ele descriptografa o que o usuário envia, inspeciona e aplica as políticas (filtragem web, antivírus, prevenção de vazamento de dados, detecção de ameaças), criptografa de novo e encaminha ao servidor, e faz o caminho inverso com as respostas. O usuário vê um cadeado e um certificado válido; o servidor vê um cliente normal. No meio, o proxy vê tudo em texto claro.
O modelo de confiança: por que é seguro e por que é perigoso
O esquema inteiro depende de uma coisa só: o navegador precisa confiar na CA do proxy. Do ponto de vista criptográfico, um certificado forjado para example.com é indistinguível da falsificação de um atacante, a não ser que quem o assinou seja confiável. O que torna a interceptação corporativa legítima, e não um ataque, é que a organização instala a sua CA privada nos trust stores dos dispositivos que administra, por group policy, por (mobile device management, o gerenciamento de dispositivos móveis) ou por uma imagem de provisionamento. Como esses dispositivos foram configurados de antemão para confiar nessa CA, os certificados forjados validam sem erro e nenhum aviso aparece.
É esse mesmo fato que torna a interceptação poderosa e arriscada ao mesmo tempo. Ela só funciona nos dispositivos gerenciados em que a CA foi instalada; um dispositivo pessoal ou não gerenciado, que nunca passou a confiar na CA, vai mostrar um aviso de certificado em todo site interceptado, e é exatamente isso que se espera de um navegador que detecta um man-in-the-middle. Além disso, a CA do proxy passa a ser uma das chaves mais sensíveis da organização: quem roubá-la pode forjar, para qualquer um desses dispositivos, um certificado confiável de qualquer site. A interceptação também concentra num único ponto o texto claro de todos os usuários, então o próprio proxy vira um alvo valioso e, em muitas jurisdições, uma obrigação legal e de privacidade (algumas categorias de tráfego, como o de bancos e o de saúde, costumam ficar fora da descriptografia exatamente por isso).
O que quebra, e por que não é erro de configuração
A interceptação falha diante de defesas criadas justamente para percebê-la, e é por isso que a lista de exceções é permanente, e não provisória.
Certificate pinning. Uma aplicação que já vem com o certificado ou a chave pública esperada recusa qualquer outro, inclusive o do seu proxy legítimo. Aplicativos de banco, vários mensageiros, canais de atualização de software e muitos agentes instalados nos dispositivos fazem pinning de propósito. Não existe configuração que faça o pinning aceitar uma CA de interceptação: ou a aplicação fica fora da interceptação, ou ela não funciona.
TLS mútuo. Quando o servidor exige um certificado de cliente, o proxy não tem a chave privada do cliente e não consegue completar o handshake no lugar dele.
Encrypted Client Hello. Num handshake moderno, o último sinal que ainda vai em texto claro é o nome do servidor, e o ECH remove esse sinal. Uma política que depende de ler o nome de destino para decidir se intercepta ou não fica sem a sua informação de entrada.
Pós-quântico e novas trocas de chave. Todo equipamento de interceptação precisa suportar o que as pontas negociam. A troca de chaves híbrida chegou aos navegadores antes de chegar à maioria dos middleboxes, e a falha aparece assim: o handshake simplesmente para de funcionar através do proxy, mas funciona na conexão direta.
QUIC. É UDP, criptografado de ponta a ponta, e a maioria dos ambientes com interceptação lida com ele bloqueando o QUIC e forçando o fallback para TCP, o que funciona até aparecer uma aplicação que não tem fallback.
Categorias legais e regulatórias. Em muitas jurisdições, o tráfego de saúde, financeiro e jurídico fica excluído, e essa exclusão é exigência de compliance, não preferência.
Como operar com honestidade
- Torne a prática pública. Usuários e reguladores devem saber que o tráfego é inspecionado, qual categoria fica de fora e quem pode ler os logs. Isso é uma decisão de governança que muita gente trata como se fosse uma configuração de firewall.
- Faça bypass por destino, e não na base da esperança. Mantenha a lista de exclusões como um registro formal, com responsáveis e datas de revisão, do mesmo jeito que qualquer exceção de política.
- Proteja a chave emissora como a de uma CA raiz. Em hardware, com acesso controlado e com log, e com um processo já ensaiado de revogação e de re-enrollment dos dispositivos, porque trocar essa chave significa mexer em todos os dispositivos gerenciados.
- Valide o lado upstream com rigor, e derrube a sessão em vez de deixar passar um certificado fraco. Os usuários atrás do proxy não têm outra defesa.
- Meça o custo. Terminar e criptografar de novo custa caro em processamento, e a interceptação é o recurso que mais vezes transforma um appliance de segurança no gargalo do caminho; é o lado da disponibilidade nessa troca, traduzido em hardware.
O cenário, por categoria
- Secure web gateways na nuvem: Zscaler, Netskope, Cloudflare, Cisco Umbrella. A interceptação acontece na borda do provedor, o que leva o texto claro para a infraestrutura de outra empresa e faz da lista de exclusões dela parte da sua política.
- Firewalls de próxima geração: Palo Alto, Fortinet, Check Point e outros, que terminam o TLS no perímetro, onde o ambiente ainda tem um.
- Plataformas dedicadas de descriptografia: F5, A10, Gigamon e similares, que descriptografam uma vez e alimentam várias ferramentas de inspeção com o mesmo texto claro, para que a operação cara aconteça uma vez só.
- Agentes no endpoint (no próprio dispositivo do usuário), que veem o texto claro dentro do dispositivo, antes de qualquer criptografia, e por isso não precisam interceptar nada: é a abordagem que cresce à medida que a interceptação na rede perde terreno.
Vale deixar clara a tendência: a cada ano, mais tráfego resiste à interceptação na rede, e mais inspeção migra para o endpoint. Um programa de segurança construído só sobre a descriptografia na rede está apoiado numa superfície que encolhe.
O que foi projetado para derrotar a interceptação
Vários mecanismos de segurança web existem justamente para detectar ou impedir um man-in-the-middle, e eles não distinguem um atacante hostil de um proxy corporativo autorizado. Eles quebram a interceptação, e entender por quê é essencial para quem opera um proxy desses.
O certificate pinning é o mais forte. Uma aplicação com pinning já vem com o certificado ou a chave pública que espera do seu servidor embutidos no código, e rejeita qualquer outro, mesmo um "válido", assinado por uma CA confiável. Como o certificado forjado é assinado pela CA do proxy, e não pela chave real do servidor, a aplicação com pinning recusa a conexão na hora. Aplicativos móveis, atualizadores de software e alguns clientes de nuvem fazem pinning, e é por isso que quem implanta interceptação mantém listas de bypass para os destinos com pinning: as únicas opções são tirar esse tráfego da descriptografia ou quebrar o aplicativo.
O (HTTP Strict Transport Security) protege o navegador contra o downgrade e impede o usuário de clicar para ignorar o aviso nos sites que o declararam, e os sites com HSTS pré-carregado (preload) ficam simplesmente inacessíveis se o certificado não validar; junto com o pinning, isso torna alguns destinos, na prática, impossíveis de interceptar.
O TLS mútuo quebra a interceptação pelo outro lado: se o servidor de destino exige um certificado de cliente, o proxy, que está no meio, não tem a chave de cliente do usuário e não consegue completar o handshake com o servidor. Como no TLS mútuo de entrada, a saída de costume é fazer bypass da descriptografia para esses destinos.
Na prática, um SSL forward proxy nunca inspeciona tudo. Uma implantação real é uma política de inspecionar por padrão, mais um conjunto de exceções mantido com cuidado para o tráfego com pinning, com autenticação mútua e com proteção legal. O artigo sobre TLS de entrada trata do caso espelhado: um reverse proxy que termina o tráfego de servidores que a organização de fato possui, onde não é preciso forjar nada, porque o proxy tem o certificado legitimamente.