Memòria cau darrere d'una VPN: què encara amaga HTTPS

Una memòria cau al costat del servidor VPN sona a amplada de banda gratuïta per a tothom qui hi ha darrere del túnel. No ho és, perquè els bytes que passen per aquell punt continuen protegits per una sessió TLS els extrems de la qual són el navegador i el lloc web. La passarel·la VPN elimina la seva pròpia xifra exterior, no la de l'aplicació. Decideix quin objecte repetit vols reutilitzar abans d'afegir maquinari.

La sessió TLS pertany al navegador

En HTTPS ordinari el navegador negocia claus amb el lloc, i cada registre després de l'apretada de mà queda xifrat per a aquell parell d'extrems. Una passarel·la VPN desxifra el túnel que ha creat i després reenvia registres TLS opacs. Pot veure destinacions, temps i volum, però no la línia de petició ni el cos de la resposta. Aquesta és la frontera amb què ha de conviure qualsevol memòria cau.

Qualsevol disseny que la trenqui és un disseny d'intercepció TLS, amb les seves pròpies conseqüències de confiança en certificats i gestió de dispositius.

CONNECT és un túnel, no una memòria cau

Un proxy directe explícit normalment rep una petició HTTP CONNECT i després retransmet bytes en tots dos sentits. Retransmetre és la paraula clau: el proxy no analitza la conversa xifrada.

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

Les capçaleres de resposta vénen del tractament del túnel que fa el proxy, no d'una còpia emmagatzemada de la pàgina. Un CONNECT correcte vol dir que el camí funciona, no que s'hagi desat res per reutilitzar. Apuntar el port 443 a una memòria cau tampoc no li ensenya a parlar TLS, perquè l'emmagatzematge requereix missatges llegibles. La configuració del client ha d'usar el paràmetre de proxy explícit admès en lloc d'una redirecció sense explicació.

Emmagatzema el que operes, no el que navegues

Quan el contingut és teu, un proxy invers pot acabar TLS i desar respostes aprovades de manera deliberada. Quan pertany a un dipòsit de paquets, usa el mirall que el projecte admet.

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

La primera ordre mostra si hi ha una zona de memòria cau configurada i on s'aplica, mentre que la segona mostra les directrius d'emmagatzematge pròpies de l'origen per a un objecte. Una memòria cau compartida ha de respectar la frescor, els controls d'emmagatzematge i els atributs de la petició que distingeixen representacions; private i no-store volen dir coses diferents i no s'ha de treure cap dels dos per augmentar la taxa d'encerts. Les regles d'emmagatzematge HTTP també limiten desar respostes a peticions autenticades, i és exactament aquí on una pàgina personalitzada es converteix en una exposició de dades. Mantén el proxy restringit a clients aprovats en lloc d'exposar un relé obert.

Mesura l'encert, no el cronòmetre

Una segona petició més ràpida no demostra que la nova memòria cau hagi fet res, perquè els navegadors i els sistemes operatius fan memòria cau agressivament pel seu compte. Demana al proxy comptadors d'encerts i fallades i observa el trànsit de l'origen durant una repetició controlada. Fes una descàrrega repetida d'un objecte conegut, amb la memòria cau activada i després evitant-la, i compara els bytes servits per l'origen en lloc del temps transcorregut. Després comprova la frontera d'autorització: un recurs que requereix inici de sessió no s'ha de servir a un altre client.

Anota la càrrega, la clau de memòria cau i la política que va permetre la reutilització. Una memòria cau és una decisió de compartir dades disfressada d'optimització.