Proxy HTTPS nghĩa là hai kết nối TLS, không phải một

Nhãn proxy HTTPS mô tả đường truyền giữa máy khách của bạn và proxy, không hơn gì thế. Nó không nói rằng trang web phía sau được mã hoá bằng chính kết nối đó, và cũng không nói rằng proxy đọc được trang. Khi bạn tách hai kết nối ra, lỗi chứng chỉ không còn bí ẩn nữa và việc so sánh với VPN trở nên cụ thể.

Hai cặp đầu mút, hai lần xác minh

Ở chế độ đường hầm thông thường có hai quan hệ TLS. Quan hệ thứ nhất chạy từ máy khách của bạn tới proxy và xác thực proxy. Quan hệ thứ hai chạy từ máy khách của bạn tới trang web bên trong đường hầm và xác thực trang web. Chúng thất bại độc lập và được cấu hình độc lập.

Chúng có quyết định tin cậy riêng, chuỗi chứng chỉ riêng và thông báo lỗi riêng. Một proxy dùng CA của tổ chức và một trang web công khai dùng chuỗi công khai hoàn toàn có thể cần cấu hình xác minh khác nhau một cách hợp lý, và đó không phải là cấu hình sai.

Hãy coi chúng là hai kết nối tình cờ dùng chung một socket, vì chúng đúng là như vậy.

CONNECT thực sự tạo đường hầm cho cái gì

Máy khách gửi yêu cầu CONNECT nêu tên máy chủ và cổng, và proxy mở một kết nối TCP tới đích đó. Sau khi proxy trả lời, các byte tiếp theo được chuyển tiếp mà không diễn giải, đó là lý do bắt tay TLS của trang web đi qua proxy nguyên vẹn. Vì vậy proxy biết tên đích và siêu dữ liệu kết nối, và nó không nhận được các trang đã giải mã từ cách sắp xếp đó.

Sự khác biệt đó chính là toàn bộ lập luận bảo mật cho chế độ đường hầm, và nó cũng là giới hạn của chế độ này.

Một proxy HTTP không có TLS trên chặng proxy vẫn mang trang web HTTPS qua CONNECT. Trao đổi giữa máy khách và proxy là công khai trong khi kết nối tới trang web thì không, và gọi toàn bộ là proxy HTTPS che đi khác biệt đó.

Chứng chỉ nào đã thất bại

Khi xác minh thất bại, hãy đọc đầu mút được nêu trong lỗi trước khi đổi bất kỳ cài đặt tin cậy nào. Hai lỗi trông giống nhau trên terminal nhưng chỉ tới những cách sửa hoàn toàn khác nhau, vì vậy câu hỏi đầu tiên luôn là kết nối nào đã bị từ chối.

curl tách các tuỳ chọn chính vì lý do này. Tệp CA của proxy cấu hình việc xác minh proxy, trong khi tệp CA cấu hình việc xác minh máy chủ, và hành vi của kho tin cậy áp dụng cũng phụ thuộc vào cách curl được biên dịch.

curl -v --proxy https://proxy.example.net:443 \
  --proxy-cacert org-ca.pem --cacert public-ca.pem https://www.example.com/

Kìm nén một bước kiểm tra không phải là sửa chữa. Nó không chứng minh được gì về bất kỳ đầu mút nào.

Kiểm tra là một cách sắp xếp khác

Kiểm tra TLS không phải là tạo đường hầm. Một bên trung gian kiểm tra sẽ kết thúc quan hệ tin cậy hướng tới trang web và trình bày chứng chỉ của chính nó cho máy khách, nên máy khách xác minh bên trung gian thay vì trang web. Điều đó có thể hợp lý theo một thiết kế đã được phê duyệt, và đó là một tuyên bố khác về bản chất so với việc chuyển tiếp từng byte. Đừng cho rằng proxy nào cũng kiểm tra, và đừng cho rằng chặng proxy đã mã hoá thì loại trừ điều đó.

Một CA của tổ chức trong kho tin cậy của bạn là gợi ý về việc bạn đang ở cách sắp xếp nào, không phải bằng chứng. Hãy hỏi về thiết kế thay vì suy ra từ chuỗi chứng chỉ.

Hai cách sắp xếp đó đưa ra câu trả lời khác nhau cho câu hỏi ai có thể đọc trang.

So sánh proxy và VPN trên cùng bốn dòng

Việc so sánh chỉ trở nên hữu ích khi cả hai cách triển khai được mô tả theo cùng một cách.

Một proxy được cấu hình cho một yêu cầu chỉ bao phủ yêu cầu đó. Nó không gửi mọi tiến trình trên thiết bị qua mình, và lệnh ví dụ đúng là hẹp như vậy. Phạm vi của VPN phụ thuộc vào định tuyến và chính sách ứng dụng của nó, cũng phải được xem xét chứ không phải giả định. Không lựa chọn nào bao phủ mọi thứ chỉ vì nó đã được cài đặt.

Hãy viết bốn dòng cho mỗi lựa chọn và cuộc tranh luận thường tự giải quyết. Việc so sánh hữu ích không phải là nhãn nào nghe có vẻ mã hoá hơn. Mà là những đoạn nào được bảo vệ, ai được xác minh ở các đầu của chúng, bạn tin tưởng những bên trung gian nào, và chính sách thực sự bao gồm lưu lượng nào.