Caché detrás dunha VPN: que segue ocultando HTTPS

Unha caché xunto ao servidor VPN soa a ancho de banda gratuíto para todos os que están detrás do túnel. Non o é, porque os bytes que pasan por ese punto seguen protexidos por unha sesión TLS cuxos extremos son o navegador e o sitio web. A pasarela VPN elimina só o seu propio cifrado exterior, non o da aplicación. Decida que obxecto repetido quere reutilizar antes de engadir hardware.

A sesión TLS pertence ao navegador

En HTTPS normal o navegador negocia claves co sitio, e cada rexistro tras o protocolo de enlace cífrase para ese par de extremos. Unha pasarela VPN descifra o túnel que creou e despois reenvía rexistros TLS opacos. Pode ver destinos, tempos e volume, pero non a liña de petición nin o corpo da resposta. Esa é a fronteira coa que debe convivir calquera caché.

Calquera deseño que a rompa é un deseño de interceptación TLS, coas súas propias consecuencias de confianza en certificados e xestión de dispositivos.

CONNECT é un túnel, non unha caché

Un proxy directo explícito adoita recibir unha petición HTTP CONNECT e despois retransmite bytes en ambos os sentidos. Retransmitir é a palabra clave: o proxy non analiza a conversa cifrada.

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

As cabeceiras de resposta veñen do manexo do túnel por parte do proxy, non dunha copia na caché da páxina. Un CONNECT correcto significa que a ruta funciona, non que se gardase algo para reutilizar. Apuntar o porto 443 a unha caché tampouco lle ensina a falar TLS, porque o almacenamento en caché esixe mensaxes lexibles. A configuración do cliente debe usar o axuste explícito de proxy admitido en lugar dunha redirección sen explicación.

Almacene en caché o que opera, non o que navega

Cando o contido é seu, un proxy inverso pode terminar TLS e gardar respostas aprobadas de forma deliberada. Cando pertence a un repositorio de paquetes, use o espello que o proxecto admite.

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 hai unha zona de caché configurada e onde se aplica, mentres que o segundo mostra as directivas de caché propias da orixe para un obxecto. Unha caché compartida debe respectar a frescura, os controis de caché e os atributos da petición que distinguen representacións; private e no-store significan cousas distintas e ningún debería eliminarse para elevar a taxa de acertos. As regras de caché HTTP tamén limitan gardar respostas a peticións autenticadas, e é xusto aí onde unha páxina personalizada se converte nunha exposición de datos. Manteña o proxy restrinxido a clientes aprobados en lugar de expoñer un relé aberto.

Mida o acerto, non o cronómetro

Unha segunda petición máis rápida non demostra que a nova caché fixese algo, porque os navegadores e os sistemas operativos cachean con agresividade pola súa conta. Pida ao proxy contadores de acertos e fallos e observe o tráfico da orixe durante unha repetición controlada. Use unha descarga repetida dun obxecto coñecido, coa caché activada e logo eludida, e compare os bytes servidos pola orixe en lugar do tempo transcorrido. Despois comprobe a fronteira de autorización: un recurso que esixe inicio de sesión non debe servirse a outro cliente.

Anote a carga, a clave de caché e a política que permitiu a reutilización. Unha caché é unha decisión de compartir datos disfrazada de optimización.