Caching hinter einem VPN: Was HTTPS weiterhin verbirgt

Ein Cache neben dem VPN-Server klingt nach kostenloser Bandbreite für alle hinter dem Tunnel. Das ist er nicht, denn die Bytes an diesem Punkt bleiben durch eine TLS-Sitzung geschützt, deren Endpunkte der Browser und die Website sind. Das VPN-Gateway entfernt nur seine eigene äußere Verschlüsselung, nicht die der Anwendung. Entscheiden Sie, welches wiederkehrende Objekt Sie wiederverwenden wollen, bevor Sie Hardware hinzufügen.

Die TLS-Sitzung gehört dem Browser

Bei gewöhnlichem HTTPS handelt der Browser Schlüssel mit der Website aus, und jeder Datensatz nach dem Handshake ist für dieses Endpunktpaar verschlüsselt. Ein VPN-Gateway entschlüsselt den von ihm erzeugten Tunnel und leitet dann undurchsichtige TLS-Datensätze weiter. Es sieht Ziele, Zeitpunkt und Volumen, nicht die Anforderungszeile oder den Antwortkörper. Das ist die Grenze, mit der jeder Cache leben muss.

Jedes Design, das sie bricht, ist ein TLS-Interzeptionsdesign mit eigenen Folgen für Zertifikatsvertrauen und Geräteverwaltung.

CONNECT ist ein Tunnel, kein Cache

Ein expliziter Forward-Proxy erhält normalerweise eine HTTP-CONNECT-Anfrage und leitet dann Bytes in beide Richtungen weiter. Weiterleiten ist das entscheidende Wort: Der Proxy wertet das verschlüsselte Gespräch nicht aus.

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

Die Antwort-Header stammen aus der Tunnelbehandlung des Proxys, nicht aus einer gecachten Kopie der Seite. Ein erfolgreiches CONNECT bedeutet, dass der Pfad funktioniert, nicht dass etwas zur Wiederverwendung gespeichert wurde. Port 443 auf einen Cache zeigen zu lassen bringt ihm TLS auch nicht bei, denn Caching erfordert lesbare Nachrichten. Die Client-Konfiguration muss die unterstützte explizite Proxy-Einstellung verwenden statt einer unerklärten Umleitung.

Cachen Sie, was Sie betreiben, nicht was Sie durchsuchen

Wo der Inhalt Ihrer ist, kann ein Reverse-Proxy TLS beenden und genehmigte Antworten bewusst speichern. Wo er einem Paket-Repository gehört, nutzen Sie den Spiegel, den das Projekt unterstützt.

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

Der erste Befehl zeigt, ob eine Cache-Zone konfiguriert ist und wo sie gilt, der zweite zeigt die eigenen Caching-Anweisungen des Ursprungs für ein Objekt. Ein gemeinsamer Cache muss Aktualität, Cache-Steuerung und die Anfrageattribute respektieren, die Repräsentationen unterscheiden; private und no-store bedeuten Unterschiedliches, und keines sollte entfernt werden, um die Trefferquote zu erhöhen. HTTP-Caching-Regeln beschränken zudem das Speichern von Antworten auf authentifizierte Anfragen, und genau dort wird eine personalisierte Seite zur Datenoffenlegung. Beschränken Sie den Proxy auf genehmigte Clients, statt ein offenes Relay anzubieten.

Messen Sie den Treffer, nicht die Stoppuhr

Eine schnellere zweite Anfrage beweist nicht, dass der neue Cache etwas bewirkt hat, denn Browser und Betriebssysteme cachen selbst aggressiv. Fragen Sie den Proxy nach Treffer- und Fehlzählern und beobachten Sie den Ursprungsverkehr bei einer kontrollierten Wiederholung. Nutzen Sie einen wiederholten Download eines bekannten Objekts, einmal mit aktivem und dann mit umgangenem Cache, und vergleichen Sie die vom Ursprung gelieferten Bytes statt der verstrichenen Zeit. Prüfen Sie dann die Autorisierungsgrenze: Eine Ressource, die eine Anmeldung erfordert, darf keinem anderen Client ausgeliefert werden.

Halten Sie Last, Cache-Schlüssel und die Richtlinie fest, die die Wiederverwendung erlaubte. Ein Cache ist eine Entscheidung über Datenweitergabe im Optimierungskostüm.