Có nên xếp chồng hai lớp VPN? Ba điều kiện cần kiểm tra

Trước khi thêm lớp mã hóa thứ hai vào một VPN, hãy trả lời thật lòng một câu hỏi: sau khi cả hai lớp đã làm xong việc của mình, kẻ quan sát còn giữ được gì? Nếu câu trả lời là bản mã bên trong, không thay đổi, thì việc lồng lớp chỉ mua thời gian và không gì khác. Phần tiếp theo là một thủ tục quyết định, không phải khuyến nghị. Cùng một sơ đồ là CPU lãng phí trong một lần triển khai và là câu trả lời đúng trong một lần khác, và chỉ ba điều kiện phân biệt hai trường hợp đó.

Ghi lại những gì kẻ quan sát giữ được

Ghi nhận đối tượng mà một kẻ đối kháng có thể lưu trữ hôm nay, rồi đến chuỗi các lần gỡ bỏ mà cuối cùng sẽ phơi bày bản rõ. Đường hầm bên ngoài tạo ra bản mã; khi lớp bảo vệ của nó kết thúc, thứ còn lại là bản mã của đường hầm bên trong, vẫn còn niêm phong. Gỡ một lớp bọc không phải là giải mã. Câu đó mô tả việc lồng lớp, và nó chỉ đúng chừng nào khóa bên trong còn sống. Ngay khi hai lớp chia sẻ bất cứ thứ gì, dòng thời gian sụp thành một sự kiện duy nhất.

Vậy sản phẩm hữu ích là một dòng thời gian, không phải sơ đồ các ô. Với mỗi lớp, hãy ghi điểm cuối, chủ sở hữu khóa, kiểm tra danh tính và năm mà giả định được cho là sẽ thất bại.

Một cách thực tế để kiểm tra tuyên bố của chính bạn: giả định kẻ quan sát ghi lại mọi thứ và không bao giờ bỏ cuộc. Dưới giả định đó, thiết kế còn bảo vệ tải trọng trong suốt vòng đời yêu cầu không? Nếu câu trả lời phụ thuộc vào việc kẻ quan sát chọn không lưu trữ lưu lượng, thì thiết kế không có câu trả lời.

Điều kiện một: các lớp có dừng ở những nơi khác nhau không?

Việc lồng lớp đáng giá khi hai lớp kết thúc ở các miền tin cậy khác nhau, ví dụ một cổng IPsec do nhà cung cấp quản lý đứng trước một đường hầm cấp ứng dụng kết thúc bên trong mạng của chính bạn. Khi đó, phá lớp ngoài cho ra bản mã mà chỉ máy chủ của bạn mở được, và nhà cung cấp không bao giờ thấy bản rõ. Đặt cả hai lớp trên cùng một cổng thì tính chất đó biến mất. Ai xâm phạm chiếc hộp sẽ đọc lưu lượng giữa hai thao tác giải mã, bất kể sơ đồ vẽ bao nhiêu lớp bọc.

Hãy kiểm tra bằng trạng thái đã cài đặt chứ không phải bằng thiết kế. Trên Linux, ip xfrm state liệt kê từng hiệp hội bảo mật và các điểm cuối của nó, điều này xác định mỗi lớp thực sự dừng ở đâu.

Điều kiện hai: vật liệu khóa có thực sự độc lập không?

Hai lớp được xây từ một chứng chỉ, một khóa chia sẻ trước hoặc một thư viện của nhà cung cấp là một lớp với các bước thêm. Khi đó một thông tin đăng nhập bị lộ mở cả hai, và một lỗi triển khai loại bỏ cả hai cùng lúc. Tính độc lập phải hiện ra trong cấu hình, không phải được khẳng định trên một trang trình bày.

Đây là nơi thiết lập khóa lai vượt qua việc xếp chồng đường hầm. IKEv2 có thể mang nhiều lần trao đổi khóa trong một cuộc thương lượng, nên một nhóm cổ điển và một KEM hậu lượng tử đều có thể nuôi cùng các khóa phiên thay vì bị quấn quanh nhau. Kết quả là một hiệp hội bảo mật duy nhất mà các khóa phụ thuộc vào cả hai bí mật, và kẻ tấn công phải phá cả hai. Đó là một cấu trúc được ghi chép với thành phần xác định, điều mà một chồng tự chế từ hai sản phẩm VPN không phải. Trên strongSwan, swanctl --list-sas in đề xuất đã thương lượng cho từng SA, và đó là cách bạn xác nhận cái gì thực sự đã chạy chứ không phải cái bạn đã cấu hình.

Điều kiện ba: dữ liệu có sống lâu hơn giả định bên ngoài không?

Một lớp phải trụ được hai mươi năm cần một lập luận hai mươi năm. Ghi lại bây giờ và giải mã sau này là rẻ, và đó là lý do một lớp ngoài cổ điển không thể bị coi là lớp bọc tạm thời quanh một thứ mạnh hơn.

Hỏi khi nào mỗi khóa trở nên có thể phục hồi, chứ không phải hôm nay mật mã đã bị phá chưa. Trao đổi khóa tĩnh không có bí mật chuyển tiếp thất bại hồi tố vào ngày khóa riêng đổ. Thỏa thuận khóa tạm thời chỉ thất bại với các phiên mà kẻ tấn công có thể tấn công khi chúng còn sống, hoặc khi bản thân thuật toán yếu đi. Sự khác biệt đó quyết định liệu lớp bên trong còn giúp ích vào năm 2040 hay không. Nó cũng quyết định liệu lớp bên ngoài có thay đổi bất cứ điều gì, vì một lớp ngoài có vòng đời khóa yếu hơn chỉ trở thành điểm sớm nhất trên dòng thời gian.

Nên xây gì thay thế khi câu trả lời là không

Nếu bất kỳ điều kiện nào trong ba điều kiện thất bại, hãy bỏ việc lồng lớp và dồn nỗ lực vào lớp thực sự mang yêu cầu về vòng đời. Cấu hình trao đổi khóa lai trong giao thức bạn đã chạy, giữ cho việc triển khai luôn cập nhật, và ghi lại thành phần mà bạn dựa vào. Nêu ML-KEM trong một tài liệu thiết kế không phải là thuộc tính bảo mật, và FIPS 203 định nghĩa cơ chế đóng gói khóa, không phải đường hầm của bạn.

Nơi lớp thứ hai thực sự xứng đáng có chỗ, hãy mô tả nó như phòng thủ theo chiều sâu chứ không phải như bằng chứng. Sau đó xác minh thành phần: điểm cuối nào giữ khóa nào, mỗi bên kiểm tra danh tính nào, và người vận hành có quyền truy cập bảng điều khiển đọc được gì. Một thiết kế vượt qua ba câu hỏi đó đáng giá phần CPU thêm. Một thiết kế không vượt qua chỉ là sơ đồ.

Trước cửa sổ thay đổi, hãy ghi lại bảng SA hiện tại và các đề xuất đã thương lượng, sau đó ghi lại lần nữa và so sánh, vì bằng chứng duy nhất quan trọng là những gì các thiết bị thực sự đồng ý.