Caché detrás de una VPN: qué sigue ocultando HTTPS

Una caché junto al servidor VPN suena a ancho de banda gratis para todos los que están detrás del túnel. No lo es, porque los bytes que pasan por ese punto siguen protegidos por una sesión TLS cuyos extremos son el navegador y el sitio web. La puerta de enlace VPN elimina su propio cifrado exterior, no el de la aplicación. Decida qué objeto repetido quiere reutilizar antes de añadir hardware.

La sesión TLS pertenece al navegador

En HTTPS normal el navegador negocia claves con el sitio, y cada registro tras el protocolo de enlace se cifra para ese par de extremos. Una puerta de enlace VPN descifra el túnel que creó y luego reenvía registros TLS opacos. Puede ver destinos, tiempos y volumen, pero no la línea de petición ni el cuerpo de la respuesta. Esa es la frontera con la que debe convivir cualquier caché.

Cualquier diseño que la rompa es un diseño de interceptación TLS, con sus propias consecuencias de confianza en certificados y gestión de dispositivos.

CONNECT es un túnel, no una caché

Un proxy directo explícito suele recibir una petición HTTP CONNECT y luego retransmite bytes en ambos sentidos. Retransmitir es la palabra clave: el proxy no analiza la conversación cifrada.

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

Las cabeceras de respuesta vienen del manejo del túnel por parte del proxy, no de una copia en caché de la página. Un CONNECT correcto significa que la ruta funciona, no que se haya guardado algo para reutilizar. Apuntar el puerto 443 a una caché tampoco le enseña a hablar TLS, porque el almacenamiento en caché exige mensajes legibles. La configuración del cliente debe usar el ajuste explícito de proxy admitido en lugar de una redirección sin explicación.

Almacene en caché lo que opera, no lo que navega

Cuando el contenido es suyo, un proxy inverso puede terminar TLS y guardar respuestas aprobadas de forma deliberada. Cuando pertenece a un repositorio de paquetes, use el espejo que el proyecto admite.

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

El primer comando muestra si hay una zona de caché configurada y dónde se aplica, mientras que el segundo muestra las directivas de caché propias del origen para un objeto. Una caché compartida debe respetar la frescura, los controles de caché y los atributos de la petición que distinguen representaciones; private y no-store significan cosas distintas y ninguno debería eliminarse para elevar la tasa de aciertos. Las reglas de caché HTTP también limitan guardar respuestas a peticiones autenticadas, y es justo ahí donde una página personalizada se convierte en una exposición de datos. Mantenga el proxy restringido a clientes aprobados en lugar de exponer un relé abierto.

Mida el acierto, no el cronómetro

Una segunda petición más rápida no demuestra que la nueva caché haya hecho algo, porque los navegadores y los sistemas operativos cachean con agresividad por su cuenta. Pida al proxy contadores de aciertos y fallos y observe el tráfico del origen durante una repetición controlada. Use una descarga repetida de un objeto conocido, con la caché activada y luego eludida, y compare los bytes servidos por el origen en lugar del tiempo transcurrido. Después compruebe la frontera de autorización: un recurso que exige inicio de sesión no debe servirse a otro cliente.

Anote la carga, la clave de caché y la política que permitió la reutilización. Una caché es una decisión de compartir datos disfrazada de optimización.