Ghim TLS và việc vào mạng qua VPN trả lời hai câu hỏi khác nhau

Đặt một ứng dụng di động riêng tư sau VPN và một người hợp lý sẽ hỏi liệu nó còn cần ghim chứng chỉ hay không. Câu hỏi nghe như một lựa chọn giữa hai biện pháp kiểm soát tương đương, nhưng thực ra là câu hỏi về hai cánh cổng khác nhau. VPN quyết định thiết bị này có được dùng đường đi hay không; ứng dụng quyết định máy chủ nó đến có phải là máy chủ nó chờ đợi hay không. Trả lời riêng cả hai và thiết kế sẽ trở nên đơn giản hơn.

Hai cổng, hai câu hỏi

Việc vào mạng liên quan đến máy khách: thiết bị này đã đăng ký chưa, thông tin xác thực của nó có hợp lệ không, và chính sách có cho nó đi theo đường này không? Niềm tin của ứng dụng liên quan đến máy chủ: kết nối có đến được một dịch vụ có danh tính mà ứng dụng chấp nhận không? Những câu trả lời này đến từ các hệ thống khác nhau, thất bại vì lý do khác nhau và được các nhóm khác nhau sửa. Một cái bắt tay VPN có thể thành công trong khi ứng dụng đang nói chuyện với chứng chỉ hết hạn phía sau đối tác. Một ứng dụng được ghim hoàn hảo vẫn có thể không ai đến được, vì thiết bị chưa bao giờ vào mạng.

Cả hai cộng lại. Bỏ một cái là bỏ một biện pháp kiểm soát; thêm cái kia không thay thế nó.

Ghim thực sự giới hạn điều gì

Ghim thu hẹp tập danh tính máy chủ mà ứng dụng sẽ chấp nhận, thường bằng cách nêu một khóa công khai hoặc một hàm băm chứng chỉ thay vì tin mọi chuỗi mà một kho nào đó bảo chứng. Đây là một ràng buộc đặt lên việc xác thực thông thường, không phải vật thay thế nó. Xác thực thông thường trả lời chuỗi có đáng tin hay không; ghim trả lời đó có phải chuỗi mà ứng dụng này chờ đợi hay không. Một cách triển khai bỏ qua bước đầu tiên không giành được bảo mật, chỉ giành được sự mới lạ.

Đối tượng được ghim khác nhau giữa các nền tảng, nên chỉ riêng từ đó nói rất ít. Sao chép một hàm băm từ kho tin cậy của một sản phẩm và coi nó là cùng một thứ trong ứng dụng di động là lỗi phổ biến và âm thầm.

Ghim trên nền tảng là cấu hình, không phải chính sách

Android công bố ghim qua cấu hình bảo mật mạng, nơi một bộ ghim giữ các bản tóm tắt của khóa công khai và chuỗi phải chứa ít nhất một trong số đó. Tệp đó là cho từng ứng dụng và cần một thay đổi bản dựng có chủ ý. iOS không có cơ chế kê khai tương đương, nên ghim ở đó sống trong mã đánh giá tin cậy của chính ứng dụng.

Vì cơ chế khác nhau, yêu cầu phải được viết cho từng nền tảng. Một chính sách nói hãy ghim chứng chỉ mà không nêu nền tảng thì không khả thi.

Luân chuyển quyết định ghim có tồn tại hay không

Phần khó không phải bản phát hành đầu tiên, mà là việc gia hạn chứng chỉ sau đó. Một chính sách tin cậy nghiêm ngặt từ chối một khóa mới hợp pháp chắc chắn như khóa của kẻ tấn công.

Hai cơ chế làm luân chuyển chịu đựng được: một ghim dự phòng đã được tin cậy trước khi cần, và một ngày hết hạn trên bộ ghim để việc thực thi lắng xuống thay vì làm ứng dụng tê liệt. Cả hai đều là quyết định chính sách, và riêng ngày hết hạn là một sự giảm bảo mật có chủ ý, không phải bộ hẹn giờ vô hại. Nêu rõ ai kiểm soát bản dựng ứng dụng, điểm cuối TLS và việc gia hạn chứng chỉ, rồi đưa họ vào một quy trình thay đổi. Nếu đó là ba nhóm khác nhau, ghim sẽ cuối cùng gây ra một sự cố mà không ai lên kế hoạch.

Thiết bị bị mất là vấn đề thứ ba

Thu hồi thông tin xác thực VPN không nhất thiết kết thúc phiên ứng dụng, và ghim máy chủ không làm gì cả với một chiếc điện thoại trong tay người khác. Khóa thiết bị, lưu trữ thông tin xác thực, thời hạn phiên và thu hồi từ xa là những quyết định riêng với chủ sở hữu riêng. Gộp chúng vào cuộc thảo luận về ghim bảo đảm không cái nào được thiết kế.

Hãy kiểm tra bốn mối quan hệ thay vì một mối bạn thấy: máy chủ và thao tác dự định, một tài khoản đáng lẽ bị từ chối, một danh tính máy chủ đáng lẽ bị loại bỏ, và việc luân chuyển đã lên kế hoạch. Một VPN đang hoạt động chỉ luyện mối đầu tiên. Ghi lại mỗi bài kiểm tra đã chứng minh điều gì, vì người tiếp theo sẽ cho rằng một đường hầm xanh nghĩa là cả bốn đều đạt.