Cache în spatele unui VPN: ce mai ascunde HTTPS

Un cache lângă serverul VPN sună ca lățime de bandă gratuită pentru toți cei din spatele tunelului. Nu este, pentru că octeții care trec prin acel punct rămân protejați de o sesiune TLS ale cărei capete sunt browserul și site-ul. Gateway-ul VPN elimină doar criptarea sa exterioară, nu pe cea a aplicației. Decideți ce obiect repetat vreți să refolosiți înainte de a adăuga hardware.

Sesiunea TLS aparține browserului

În HTTPS obișnuit browserul negociază chei cu site-ul, iar fiecare înregistrare după strângerea de mână este criptată pentru acea pereche de capete. Un gateway VPN decriptează tunelul pe care l-a creat și apoi retransmite înregistrări TLS opace. Vede destinații, momente și volum, nu linia cererii sau corpul răspunsului. Aceasta este granița cu care trebuie să trăiască orice cache.

Orice proiect care o încalcă este un proiect de interceptare TLS, cu propriile consecințe asupra încrederii în certificate și a administrării dispozitivelor.

CONNECT este un tunel, nu un cache

Un proxy forward explicit primește de obicei o cerere HTTP CONNECT și apoi retransmite octeți în ambele direcții. Retransmiterea este cuvântul cheie: proxy-ul nu analizează conversația criptată.

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

Antetele răspunsului vin din tratarea tunelului de către proxy, nu dintr-o copie cache a paginii. Un CONNECT reușit înseamnă că traseul funcționează, nu că ceva a fost păstrat pentru refolosire. Direcționarea portului 443 către un cache nici nu îl învață să vorbească TLS, pentru că cache-ul cere mesaje lizibile. Configurația clientului trebuie să folosească setarea explicită de proxy acceptată, nu o redirecționare neexplicată.

Cache-uiți ce operați, nu ce navigați

Când conținutul este al dumneavoastră, un proxy invers poate termina TLS și poate stoca deliberat răspunsuri aprobate. Când aparține unui depozit de pachete, folosiți oglinda acceptată de proiect.

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

Prima comandă arată dacă o zonă de cache este configurată și unde se aplică, iar a doua arată directivele de cache ale originii pentru un obiect. Un cache partajat trebuie să respecte prospețimea, controalele de cache și atributele cererii care disting reprezentările; private și no-store înseamnă lucruri diferite și niciunul nu trebuie eliminat pentru a crește rata de potriviri. Regulile de cache HTTP limitează și stocarea răspunsurilor la cereri autentificate, și exact acolo o pagină personalizată devine o expunere de date. Țineți proxy-ul restricționat la clienți aprobați în loc să expuneți un relay deschis.

Măsurați potrivirea, nu cronometrul

O a doua cerere mai rapidă nu dovedește că noul cache a făcut ceva, pentru că browserele și sistemele de operare fac cache agresiv pe cont propriu. Cereți proxy-ului contoare de potriviri și ratări și urmăriți traficul originii într-o repetare controlată. Folosiți o descărcare repetată a unui obiect cunoscut, cu cache-ul activat și apoi ocolit, și comparați octeții serviți de origine, nu timpul scurs. Apoi verificați granița de autorizare: o resursă care cere autentificare nu trebuie servită altui client.

Notați încărcarea, cheia de cache și politica ce a permis refolosirea. Un cache este o decizie de partajare a datelor deghizată în optimizare.