VPN 뒤의 캐시: HTTPS가 여전히 감추는 것

VPN 서버 옆에 캐시를 두면 터널 뒤의 모든 사람에게 무료 대역폭이 생길 것처럼 들립니다. 그렇지 않습니다. 그 지점을 지나는 바이트는 브라우저와 사이트를 양 끝으로 하는 TLS 세션으로 계속 보호되기 때문입니다. VPN 게이트웨이는 자신의 바깥쪽 암호화만 벗기고, 애플리케이션의 암호화는 벗기지 않습니다. 하드웨어를 더하기 전에 어떤 반복 객체를 재사용할지 정하세요.

TLS 세션은 브라우저의 것

일반 HTTPS에서 브라우저는 사이트와 키를 협상하고, 핸드셰이크 이후의 모든 레코드는 그 양 끝 쌍을 위해 암호화됩니다. VPN 게이트웨이는 자기가 만든 터널을 복호화한 뒤 불투명한 TLS 레코드를 전달합니다. 볼 수 있는 것은 목적지, 시점, 양이며 요청 줄이나 응답 본문이 아닙니다. 이것이 모든 캐시가 감수해야 하는 경계입니다.

이를 깨는 설계는 TLS 가로채기 설계이며, 인증서 신뢰와 기기 관리에 나름의 결과를 낳습니다.

CONNECT는 터널이지 캐시가 아니다

명시적 포워드 프록시는 보통 HTTP CONNECT 요청을 받은 뒤 양방향으로 바이트를 중계합니다. 중계가 핵심 단어입니다. 프록시는 암호화된 대화를 해석하지 않습니다.

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

응답 헤더는 프록시의 터널 처리에서 나오며, 페이지의 캐시 사본에서 나오지 않습니다. CONNECT 성공은 경로가 동작한다는 뜻이지, 무언가가 재사용을 위해 저장되었다는 뜻이 아닙니다. 포트 443을 캐시로 돌리는 것 도 TLS를 말하도록 가르치지 않습니다. 캐시에는 읽을 수 있는 메시지가 필요하기 때문입니다. 클라이언트 설정은 설명 없는 리디렉션이 아니라 지원되는 명시적 프록시 설정을 사용해야 합니다.

운영하는 것을 캐시하고, 탐색하는 것은 캐시하지 마세요

콘텐츠가 내 것이라면 리버스 프록시가 TLS를 종료하고 승인된 응답을 의도적으로 저장할 수 있습니다. 콘텐츠가 패키지 저장소의 것이라면 프로젝트가 지원하는 미러를 사용하세요.

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

첫 번째 명령은 캐시 영역이 구성되었는지와 어디에 적용되는지를 보여 주고, 두 번째는 한 객체에 대한 오리진 자체의 캐시 지시를 보여 줍니다. 공유 캐시는 신선도, 캐시 제어, 표현을 구분하는 요청 속성을 존중해야 합니다. private 그리고 no-store 는 다른 뜻이며 적중률을 높이려고 어느 것도 제거해서는 안 됩니다. HTTP 캐시 규칙은 인증된 요청에 대한 응답 저장도 제한하며, 바로 그 지점에서 개인화 페이지가 데이터 노출이 됩니다. 프록시를 열린 릴레이로 노출하지 말고 승인된 클라이언트로 제한하세요.

적중을 측정하고, 초시계는 측정하지 마세요

두 번째 요청이 빠르다는 것은 새 캐시가 무언가 했다는 증거가 아닙니다. 브라우저와 운영체제가 스스로 공격적으로 캐시하기 때문입니다. 프록시에 적중과 미스 카운터를 요청하고 통제된 반복 동안 오리진 트래픽을 지켜보세요. 알려진 객체를 한 번 반복 다운로드하면서 캐시를 켠 경우와 우회한 경우를 비교하되, 경과 시간이 아니라 오리진이 제공한 바이트를 비교하세요. 그다음 권한 경계를 확인하세요. 로그인이 필요한 리소스는 다른 클라이언트에 제공되어서는 안 됩니다.

워크로드, 캐시 키, 재사용을 허용한 정책을 기록하세요. 캐시는 최적화 옷을 입은 데이터 공유 결정입니다.