Pamięć podręczna za VPN: co nadal ukrywa HTTPS

Pamięć podręczna obok serwera VPN brzmi jak darmowe pasmo dla wszystkich za tunelem. Nie jest, bo bajty przechodzące przez ten punkt pozostają chronione sesją TLS, której końcami są przeglądarka i witryna. Brama VPN usuwa tylko własne zewnętrzne szyfrowanie, nie szyfrowanie aplikacji. Zdecyduj, który powtarzalny obiekt chcesz użyć ponownie, zanim dodasz sprzęt.

Sesja TLS należy do przeglądarki

W zwykłym HTTPS przeglądarka negocjuje klucze z witryną, a każdy rekord po uścisku dłoni jest szyfrowany dla tej pary końców. Brama VPN odszyfrowuje utworzony przez siebie tunel, a następnie przekazuje nieprzejrzyste rekordy TLS. Widzi cele, czas i wolumen, ale nie linię żądania ani treść odpowiedzi. To granica, z którą musi żyć każda pamięć podręczna.

Każdy projekt, który ją łamie, jest projektem przechwytywania TLS, z własnymi konsekwencjami dla zaufania do certyfikatów i zarządzania urządzeniami.

CONNECT to tunel, nie pamięć podręczna

Jawny proxy przekazujący zwykle otrzymuje żądanie HTTP CONNECT, a następnie przekazuje bajty w obu kierunkach. Przekazywanie to słowo kluczowe: proxy nie analizuje zaszyfrowanej rozmowy.

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

Nagłówki odpowiedzi pochodzą z obsługi tunelu przez proxy, nie z kopii strony w pamięci podręcznej. Udany CONNECT oznacza, że ścieżka działa, a nie że coś zapisano do ponownego użycia. Kierowanie portu 443 na pamięć podręczną też nie nauczy go mówić TLS, bo buforowanie wymaga czytelnych komunikatów. Konfiguracja klienta musi używać obsługiwanego jawnego ustawienia proxy, a nie niewyjaśnionego przekierowania.

Buforuj to, co obsługujesz, nie to, co przeglądasz

Gdy treść jest twoja, odwrotny proxy może zakończyć TLS i świadomie przechowywać zatwierdzone odpowiedzi. Gdy należy do repozytorium pakietów, użyj lustra obsługiwanego przez projekt.

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

Pierwsze polecenie pokazuje, czy strefa pamięci podręcznej jest skonfigurowana i gdzie obowiązuje, a drugie pokazuje własne dyrektywy buforowania źródła dla jednego obiektu. Wspólna pamięć podręczna musi respektować świeżość, mechanizmy kontroli pamięci podręcznej i atrybuty żądania, które rozróżniają reprezentacje; private i no-store znaczą różne rzeczy i żadnego nie należy usuwać, aby podnieść współczynnik trafień. Reguły buforowania HTTP ograniczają też przechowywanie odpowiedzi na uwierzytelnione żądania, i właśnie tam spersonalizowana strona staje się ujawnieniem danych. Trzymaj proxy ograniczone do zatwierdzonych klientów, zamiast wystawiać otwarty relay.

Mierz trafienie, nie stoper

Szybsze drugie żądanie nie dowodzi, że nowa pamięć podręczna coś zrobiła, bo przeglądarki i systemy operacyjne buforują same, agresywnie. Poproś proxy o liczniki trafień i chybień i obserwuj ruch źródła podczas kontrolowanego powtórzenia. Użyj jednego powtórzonego pobrania znanego obiektu, najpierw z włączoną pamięcią podręczną, potem z pominięciem, i porównaj bajty dostarczone przez źródło, a nie upływ czasu. Następnie sprawdź granicę autoryzacji: zasób wymagający logowania nie może być wydany innemu klientowi.

Zapisz obciążenie, klucz pamięci podręcznej i politykę, która pozwoliła na ponowne użycie. Pamięć podręczna to decyzja o udostępnianiu danych w stroju optymalizacji.