La cache dietro una VPN: cosa nasconde ancora HTTPS

Una cache accanto al server VPN sembra banda gratis per tutti quelli dietro il tunnel. Non lo è, perché i byte che passano in quel punto restano protetti da una sessione TLS i cui estremi sono il browser e il sito. Il gateway VPN rimuove solo la propria cifratura esterna, non quella dell'applicazione. Decidi quale oggetto ripetuto vuoi riusare prima di aggiungere hardware.

La sessione TLS appartiene al browser

Nell'HTTPS ordinario il browser negozia chiavi con il sito, e ogni record dopo lo handshake è cifrato per quella coppia di estremi. Un gateway VPN decifra il tunnel che ha creato e poi inoltra record TLS opachi. Vede destinazioni, tempi e volume, non la riga di richiesta o il corpo della risposta. È il confine con cui ogni cache deve convivere.

Qualsiasi progetto che lo infranga è un progetto di intercettazione TLS, con le sue conseguenze su fiducia dei certificati e gestione dei dispositivi.

CONNECT è un tunnel, non una cache

Un proxy in avanti esplicito di solito riceve una richiesta HTTP CONNECT e poi inoltra byte in entrambe le direzioni. Inoltrare è la parola chiave: il proxy non analizza la conversazione cifrata.

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

Le intestazioni di risposta derivano dalla gestione del tunnel da parte del proxy, non da una copia in cache della pagina. Un CONNECT riuscito significa che il percorso funziona, non che qualcosa sia stato memorizzato per il riuso. Puntare la porta 443 su una cache non gli insegna nemmeno a parlare TLS, perché la cache richiede messaggi leggibili. La configurazione del client deve usare l'impostazione esplicita di proxy supportata, non un reindirizzamento inspiegato.

Metti in cache ciò che gestisci, non ciò che navighi

Dove il contenuto è tuo, un proxy inverso può terminare TLS e memorizzare di proposito risposte approvate. Dove appartiene a un repository di pacchetti, usa lo specchio supportato dal progetto.

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

Il primo comando mostra se è configurata una zona cache e dove si applica, mentre il secondo mostra le direttive di cache dell'origine per un oggetto. Una cache condivisa deve rispettare freschezza, controlli di cache e gli attributi della richiesta che distinguono le rappresentazioni; private e no-store significano cose diverse e nessuno dei due va rimosso per alzare il tasso di successo. Le regole di cache HTTP limitano anche a memorizzare risposte a richieste autenticate, ed è proprio lì che una pagina personalizzata diventa un'esposizione di dati. Mantieni il proxy limitato a client approvati invece di esporre un relay aperto.

Misura il successo, non il cronometro

Una seconda richiesta più veloce non prova che la nuova cache abbia fatto qualcosa, perché browser e sistemi operativi fanno cache in modo aggressivo da soli. Chiedi al proxy i contatori di successi e mancati successi e osserva il traffico dell'origine durante una ripetizione controllata. Usa un download ripetuto di un oggetto noto, prima con la cache attiva e poi aggirata, e confronta i byte serviti dall'origine invece del tempo trascorso. Poi verifica il confine di autorizzazione: una risorsa che richiede l'accesso non deve essere servita a un altro client.

Annota il carico, la chiave di cache e la politica che ha permesso il riuso. Una cache è una decisione di condivisione dei dati travestita da ottimizzazione.