Cache atrás de uma VPN: o que o HTTPS ainda esconde

Um cache ao lado do servidor VPN soa a largura de banda grátis para todos atrás do túnel. Não é, porque os bytes que passam nesse ponto continuam protegidos por uma sessão TLS cujas pontas são o navegador e o site. O gateway VPN remove apenas a sua própria cifragem externa, não a da aplicação. Decida que objeto repetido pretende reutilizar antes de adicionar hardware.

A sessão TLS pertence ao navegador

No HTTPS comum o navegador negoceia chaves com o site, e cada registo depois do handshake é cifrado para esse par de pontas. Um gateway VPN desencripta o túnel que criou e depois encaminha registos TLS opacos. Vê destinos, tempos e volume, não a linha do pedido nem o corpo da resposta. É a fronteira com que qualquer cache tem de viver.

Qualquer desenho que a quebre é um desenho de interceção TLS, com as suas próprias consequências na confiança dos certificados e na gestão de dispositivos.

CONNECT é um túnel, não um cache

Um proxy forward explícito recebe normalmente um pedido HTTP CONNECT e depois retransmite bytes nos dois sentidos. Retransmitir é a palavra-chave: o proxy não analisa a conversa cifrada.

curl -sSI -x http://proxy.example:3128 https://example.com/

Os cabeçalhos de resposta vêm do tratamento do túnel pelo proxy, não de uma cópia em cache da página. Um CONNECT bem-sucedido significa que o caminho funciona, não que algo ficou guardado para reutilização. Apontar a porta 443 para um cache também não o ensina a falar TLS, porque a cache exige mensagens legíveis. A configuração do cliente tem de usar a definição explícita de proxy suportada, e não um redirecionamento sem explicação.

Coloque em cache o que opera, não o que navega

Quando o conteúdo é seu, um proxy inverso pode terminar TLS e guardar respostas aprovadas de forma deliberada. Quando pertence a um repositório de pacotes, use o espelho suportado pelo projeto.

nginx -T | grep -n "proxy_cache"
curl -sSI https://mirror.example/pkg/index.json | grep -i -E "cache-control|age"

O primeiro comando mostra se existe uma zona de cache configurada e onde se aplica, enquanto o segundo mostra as diretivas de cache da origem para um objeto. Um cache partilhado tem de respeitar a frescura, os controlos de cache e os atributos do pedido que distinguem representações; private e no-store significam coisas diferentes e nenhum deve ser removido para subir a taxa de acertos. As regras de cache HTTP também limitam guardar respostas a pedidos autenticados, e é exatamente aí que uma página personalizada se torna uma exposição de dados. Mantenha o proxy restrito a clientes aprovados em vez de expor um relay aberto.

Meça o acerto, não o cronómetro

Um segundo pedido mais rápido não prova que a nova cache fez algo, porque navegadores e sistemas operativos fazem cache de forma agressiva por conta própria. Peça ao proxy contadores de acertos e falhas e observe o tráfego da origem durante uma repetição controlada. Use um download repetido de um objeto conhecido, com a cache ligada e depois contornada, e compare os bytes servidos pela origem em vez do tempo decorrido. Depois verifique a fronteira de autorização: um recurso que exige login não deve ser servido a outro cliente.

Registe a carga, a chave de cache e a política que permitiu a reutilização. Um cache é uma decisão de partilha de dados disfarçada de otimização.