Le cache derrière un VPN : ce que HTTPS cache encore

Un cache à côté du serveur VPN ressemble à de la bande passante gratuite pour tous ceux qui sont derrière le tunnel. Ce n'est pas le cas, car les octets qui passent par ce point restent protégés par une session TLS dont les extrémités sont le navigateur et le site. La passerelle VPN retire son propre chiffrement externe, pas celui de l'application. Décidez quel objet répété vous voulez réutiliser avant d'ajouter du matériel.

La session TLS appartient au navigateur

En HTTPS ordinaire, le navigateur négocie des clés avec le site, et chaque enregistrement après la poignée de main est chiffré pour cette paire d'extrémités. Une passerelle VPN déchiffre le tunnel qu'elle a créé, puis transmet des enregistrements TLS opaques. Elle voit les destinations, le rythme et le volume, pas la ligne de requête ni le corps de la réponse. C'est la frontière avec laquelle tout cache doit vivre.

Toute conception qui la brise est une conception d'interception TLS, avec ses propres conséquences sur la confiance dans les certificats et la gestion des appareils.

CONNECT est un tunnel, pas un cache

Un proxy sortant explicite reçoit généralement une requête HTTP CONNECT puis relaie les octets dans les deux sens. Relayer est le mot clé : le proxy n'analyse pas la conversation chiffrée.

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

Les en-têtes de réponse viennent du traitement du tunnel par le proxy, pas d'une copie en cache de la page. Un CONNECT réussi signifie que le chemin fonctionne, pas que quelque chose a été stocké pour réutilisation. Pointer le port 443 vers un cache ne lui apprend pas non plus à parler TLS, car la mise en cache exige des messages lisibles. La configuration du client doit utiliser le réglage explicite de proxy pris en charge plutôt qu'une redirection inexpliquée.

Mettez en cache ce que vous exploitez, pas ce que vous naviguez

Quand le contenu est le vôtre, un proxy inverse peut terminer TLS et stocker délibérément des réponses approuvées. Quand il appartient à un dépôt de paquets, utilisez le miroir que le projet prend en charge.

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

La première commande montre si une zone de cache est configurée et où elle s'applique, la seconde montre les directives de cache propres à l'origine pour un objet. Un cache partagé doit respecter la fraîcheur, les contrôles de cache et les attributs de requête qui distinguent les représentations ; private et no-store signifient des choses différentes et aucun ne doit être retiré pour augmenter le taux de succès. Les règles de cache HTTP limitent aussi le stockage des réponses aux requêtes authentifiées, et c'est précisément là qu'une page personnalisée devient une fuite de données. Gardez le proxy limité à des clients approuvés au lieu d'exposer un relais ouvert.

Mesurez le succès, pas le chronomètre

Une seconde requête plus rapide ne prouve pas que le nouveau cache a fait quoi que ce soit, car les navigateurs et les systèmes d'exploitation mettent agressivement en cache de leur côté. Demandez au proxy des compteurs de succès et d'échec et observez le trafic de l'origine lors d'une répétition contrôlée. Utilisez un téléchargement répété d'un objet connu, avec le cache activé puis contourné, et comparez les octets servis par l'origine plutôt que le temps écoulé. Vérifiez ensuite la frontière d'autorisation : une ressource qui exige une connexion ne doit pas être servie à un autre client.

Notez la charge, la clé de cache et la politique qui a autorisé la réutilisation. Un cache est une décision de partage de données déguisée en optimisation.