Bộ nhớ đệm sau VPN: HTTPS vẫn che giấu điều gì

Một bộ nhớ đệm bên cạnh máy chủ VPN nghe như băng thông miễn phí cho mọi người sau đường hầm. Không phải vậy, vì các byte đi qua điểm đó vẫn được bảo vệ bởi phiên TLS mà hai đầu là trình duyệt và trang web. Cổng VPN chỉ gỡ lớp mã hóa bên ngoài của chính nó, không gỡ của ứng dụng. Hãy quyết định đối tượng lặp lại nào bạn muốn dùng lại trước khi thêm phần cứng.

Phiên TLS thuộc về trình duyệt

Trong HTTPS thông thường, trình duyệt thương lượng khóa với trang, và mọi bản ghi sau bắt tay đều được mã hóa cho cặp đầu đó. Cổng VPN giải mã đường hầm nó tạo ra rồi chuyển tiếp các bản ghi TLS không trong suốt. Nó thấy đích đến, thời điểm và khối lượng, không thấy dòng yêu cầu hay phần thân phản hồi. Đó là ranh giới mà mọi bộ nhớ đệm phải sống chung.

Bất kỳ thiết kế nào phá vỡ ranh giới đó đều là thiết kế chặn TLS, với những hệ quả riêng về niềm tin chứng thư và quản lý thiết bị.

CONNECT là đường hầm, không phải bộ nhớ đệm

Proxy chuyển tiếp rõ ràng thường nhận yêu cầu HTTP CONNECT rồi chuyển byte theo cả hai chiều. Chuyển tiếp là từ khóa: proxy không phân tích cuộc trò chuyện đã mã hóa.

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

Tiêu đề phản hồi đến từ cách proxy xử lý đường hầm, không từ bản sao trang được lưu đệm. CONNECT thành công nghĩa là đường đi hoạt động, không phải rằng có gì đó đã được lưu để dùng lại. Trỏ cổng 443 vào bộ nhớ đệm cũng không dạy nó nói TLS, vì lưu đệm cần thông điệp đọc được. Cấu hình máy khách phải dùng thiết lập proxy rõ ràng được hỗ trợ, không phải chuyển hướng không giải thích.

Lưu đệm thứ bạn vận hành, không phải thứ bạn duyệt

Khi nội dung là của bạn, proxy ngược có thể kết thúc TLS và cố ý lưu các phản hồi đã được phê duyệt. Khi nó thuộc về kho gói, hãy dùng bản sao mà dự án hỗ trợ.

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

Lệnh đầu tiên cho biết vùng đệm đã được cấu hình chưa và áp dụng ở đâu, lệnh thứ hai cho thấy chỉ dẫn lưu đệm của chính nguồn cho một đối tượng. Bộ nhớ đệm chia sẻ phải tôn trọng độ mới, các kiểm soát đệm và thuộc tính yêu cầu phân biệt các biểu diễn; private và no-store có nghĩa khác nhau và không nên gỡ bỏ cái nào để tăng tỷ lệ trúng. Quy tắc lưu đệm HTTP cũng hạn chế lưu phản hồi cho yêu cầu đã xác thực, và chính ở đó một trang cá nhân hóa trở thành rò rỉ dữ liệu. Giữ proxy chỉ dành cho máy khách đã phê duyệt thay vì phơi bày một relay mở.

Đo tỷ lệ trúng, không đo đồng hồ bấm giây

Yêu cầu thứ hai nhanh hơn không chứng minh bộ nhớ đệm mới đã làm gì, vì trình duyệt và hệ điều hành tự lưu đệm rất mạnh. Hỏi proxy bộ đếm trúng và trượt, đồng thời theo dõi lưu lượng nguồn trong một lần lặp có kiểm soát. Dùng một lần tải xuống lặp lại của một đối tượng đã biết, trước hết bật đệm rồi bỏ qua, và so sánh số byte nguồn đã phục vụ thay vì thời gian trôi qua. Sau đó kiểm tra ranh giới ủy quyền: tài nguyên yêu cầu đăng nhập không được phục vụ cho máy khách khác.

Ghi lại khối lượng công việc, khóa đệm và chính sách đã cho phép dùng lại. Bộ nhớ đệm là một quyết định chia sẻ dữ liệu trong bộ áo tối ưu hóa.