Mã hóa của đường hầm WSS dừng ở bộ kết thúc TLS, không phải ở ứng dụng

Đường hầm được chở bên trong một WebSocket bảo mật có đúng lượng mã hóa mà khách hàng đã đặt vào, không hơn. Lược đồ wss:// nói rằng TLS bảo vệ một kết nối trên một chặng. Nó không nói gì về việc các byte bên trong thông điệp WebSocket có được bảo vệ riêng hay không, và chính khác biệt đó quyết định ai có thể đọc lưu lượng của bạn khi có thứ gì đó ở giữa kết thúc TLS.

Hai tầng trông như một

WebSocket bảo mật là TLS có bắt tay WebSocket thực hiện bên trên, như RFC 6455 mô tả trong các phần về kết nối và bảo mật. Tầng TLS xác thực máy chủ và mã hóa luồng, sau đó tầng WebSocket đóng khung thứ mà ứng dụng quyết định gửi.

Đây là hai quyết định độc lập, và một sơ đồ chỉ vẽ một ổ khóa trên toàn bộ đường đi sẽ giấu đi quyết định thứ hai. Hãy hỏi ai kết thúc kết nối TLS. Sau đó hỏi khách hàng đặt gì vào bên trong mỗi thông điệp. Mọi thứ còn lại về việc triển khai đều suy ra từ hai câu trả lời đó.

Thiết kế A: lớp truyền tải là mã hóa duy nhất

Trong thiết kế đơn giản hơn, khách hàng lấy các gói IP thô và bọc chúng trong thông điệp WebSocket. Bên trong không có gì được mã hóa, nên thành phần giữ phiên TLS đọc phần tải ở dạng văn bản thuần. Khi thành phần đó là máy chủ đường hầm của chính bạn, đây là điểm cuối dự định và thiết kế nhất quán, vì máy chủ dù sao cũng sẽ thấy lưu lượng.

Nó trở thành một cách bố trí khác khi một proxy kiểm tra ngồi trên đường đi và kết thúc TLS bằng chứng chỉ mà khách hàng tin tưởng. Proxy đó giờ giữ đúng văn bản thuần mà máy chủ lẽ ra đã giữ, và không lượng đóng khung WebSocket nào thay đổi được điều đó. Kho tin cậy của khách hàng đã quyết định kết quả này từ rất lâu trước khi đường hầm mở ra, vì nó đã chọn chấp nhận chứng chỉ đó cho tên đó. Proxy cũng thấy máy chủ được yêu cầu và kích thước của từng thông điệp, đủ để lấy dấu vân tay của nhiều hoạt động mà không cần giải mã thêm gì.

Thiết kế B: phần tải mang khóa riêng

Trong thiết kế thứ hai, khách hàng mã hóa và xác thực các gói của mình bằng một giao thức VPN có danh tính đối tác và trao đổi khóa riêng, rồi chở kết quả bên trong thông điệp WebSocket. Kết thúc TLS bên ngoài ở đây phơi ra bản mã, không phải lưu lượng. Proxy có thể thấy kích thước và thời điểm của thông điệp, và không gì khác trong phần tải. Đó là mức phơi nhiễm nhỏ hơn nhiều, và nó vẫn là siêu dữ liệu đáng được nêu tên trong một buổi đánh giá thay vì gạt đi.

Các điểm cuối của chính giao thức bên trong vẫn thấy văn bản thuần, đó là ý nghĩa của cách bố trí này và cũng là giới hạn của nó. Nếu một thành phần tại điểm cuối được phép đọc dữ liệu trước khi mã hóa hoặc sau khi giải mã, lớp thêm vào không ràng buộc nó. Khóa, và phần mềm xử lý khóa, vẫn là ranh giới có ý nghĩa.

Nhãn VPN, biểu tượng khách hàng quen thuộc hay trang tiếp thị không phải bằng chứng rằng thiết kế này tồn tại. Đọc định dạng phần tải mới là bằng chứng.

Truy xem văn bản thuần thực sự xuất hiện ở đâu

Lược đồ URL chỉ cho bạn một dữ kiện, nên lấy phần còn lại từ các giao diện. Chạy các kiểm tra dưới đây theo thứ tự, vì mỗi bước thu hẹp bước tiếp theo:

ss -tnp | grep -E ':(443|8443)\b'
ip -br link show type tun
openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -brief
tcpdump -ni tun0 -c 5 -X

Bắt đầu với kết nối bên ngoài. Một phiên TCP sống lâu tới cổng TLS chính là diện mạo của một vật mang WebSocket, và phiên thứ hai tới một máy chủ không liên quan đáng được giải thích trước khi nhìn sâu hơn. Tiếp theo hãy tìm giao diện đường hầm trên khách hàng, vì thiết bị tun hoặc tap cho bạn biết khách hàng đang xử lý gói IP chứ không phải proxy một luồng ứng dụng.

Việc bắt gói trên giao diện đường hầm thường giải quyết câu hỏi về phần tải. Tiêu đề đọc được ở đó nghĩa là các gói bên trong chưa bao giờ được mã hóa riêng, còn phần tải có entropy cao nghĩa là chúng đã được mã hóa. Lặp lại việc bắt gói trên giao diện bên ngoài và so sánh hai bên: nếu cả hai đều trông ngẫu nhiên, lớp bên trong đang làm công việc mà lớp bên ngoài không thể hoàn tác.

Xem lại mức tin cậy bạn thực sự đã trao

Một chứng chỉ gốc doanh nghiệp được cài đặt là sự kiện về kho tin cậy của khách hàng, không phải tuyên bố về việc proxy nào ghi lại hay kiểm tra cái gì. Hãy xác lập chính sách đã triển khai và đường kết nối thực tế thay vì suy ra hành vi từ việc có một CA.

Trên thiết bị được quản lý, hãy hỏi quản trị viên thành phần nào kết thúc TLS, khách hàng xác thực chứng chỉ ghim hay chứng chỉ công khai, và định dạng phần tải là gì. Ba câu trả lời đó tạo ra một phát hiện mà sau này bạn có thể bảo vệ.

Viết kết quả như một ranh giới chứ không phải một phán quyết. "TLS kết thúc tại proxy kiểm tra, và phần tải bên trong được mã hóa riêng bằng khóa chỉ các điểm cuối nắm giữ" là một phát biểu kiểm chứng được và vẫn đúng khi đổi nhà cung cấp. "WebSockets là an toàn" thì không.