Vì sao khóa OpenVPN lớn hơn không loại bỏ bộ hẹn giờ tái tạo khóa

Việc chọn AES-256 hay một khóa dài hơn không nói lên điều gì về thời gian được phép dùng khóa đó. Độ mạnh của khóa mô tả thuật toán; chính sách tái tạo khóa quyết định thời điểm phiên nhận vật liệu khóa mới. Một triển khai có thể chọn mã hóa mạnh nhất hiện có mà vẫn sai về việc gia hạn, vì hai quyết định đó được đưa ra ở hai nơi khác nhau. Nhầm lẫn chúng sẽ tạo ra hoặc một thay đổi mã hóa không cần thiết, hoặc một phiên âm thầm sống lâu hơn chính sách của nó.

Hãy đọc cấu hình tái tạo khóa trước khi chạm vào mã hóa, và đọc cả hai phía khi làm việc đó.

Độ mạnh của khóa và tuổi thọ của khóa trả lời hai câu hỏi khác nhau

Mã hóa và kích thước khóa giới hạn mức chi phí của một cuộc tấn công vào lưu lượng bị chặn. Khoảng tái tạo khóa giới hạn lượng lưu lượng mà một khóa bảo vệ và thời gian một khóa bị lộ còn hữu ích. Đây là những điều khiển độc lập, và mã hóa mạnh hơn không kéo dài tuổi thọ an toàn của một phiên. Phần lớn hướng dẫn nói 'dùng AES-256' im lặng về việc gia hạn, vì gia hạn là câu hỏi chính sách chứ không phải lựa chọn thuật toán.

Ghi cả hai vào ghi chú triển khai: điều gì bảo vệ kênh dữ liệu và điều gì kích hoạt việc thay khóa của kênh đó.

Tái tạo khóa có ba ngưỡng kích hoạt, và cả hai phía đều có thể kích hoạt chúng

OpenVPN 2.6 ghi nhận các ngưỡng kích hoạt riêng cho việc đàm phán lại dựa trên byte, gói tin và thời gian trôi qua. Ngưỡng kích hoạt theo thời gian là ngưỡng mà phần lớn triển khai để nguyên giá trị mặc định, nghĩa là một đường hầm im ắng vẫn tái tạo khóa theo lịch. Cả hai phía đều có thể bắt đầu trao đổi, và phía không khởi xướng sẽ đi theo. Vì vậy đổi bộ hẹn giờ ở một phía không quyết định hành vi của phiên; giá trị hiệu lực là của phía khởi xướng trước.

Ngưỡng kích hoạt theo byte và gói tin quan trọng với khối lượng công việc thông lượng cao hoặc gói tin nhỏ, nơi chính sách chỉ dựa trên thời gian sẽ để một khóa bảo vệ nhiều dữ liệu hơn dự định. Nếu các bộ đếm đó vẫn tắt, hãy nói rõ điều đó một cách có chủ đích trong ghi chú thay vì để mặc định mà không xem xét.

Tái tạo khóa phơi bày quy trình xác thực

Đàm phán lại là một bắt tay TLS mới, nghĩa là đường xác thực chạy lại. Những triển khai dùng mã một lần, token phần cứng hoặc thử thách RADIUS phát hiện điều này theo cách khó khăn: kết nối đầu tiên chạy được và phiên chết một giờ sau đó khi bắt tay thứ hai đòi một mã đã được dùng. auth-gen-token tồn tại để lấp khoảng trống đó bằng cách cho máy chủ phát hành một token ngắn hạn cho việc đàm phán lại thay vì yêu cầu một lần đăng nhập tương tác mới.

Hãy coi đó là vấn đề quy trình làm việc cần giải quyết với người vận hành, không phải bằng chứng cho thấy phải tắt việc gia hạn.

Hãy thử việc gia hạn dưới tải, không phải trong một phiên một phút

Một bài kiểm thử chấp nhận chỉ kết nối, ping một lần rồi ngắt sẽ không bao giờ chạm tới việc tái tạo khóa. Hãy chạy một phiên đủ dài để vượt ngưỡng kích hoạt đã cấu hình, giữ một luồng truyền chạy suốt thời gian đó, và theo dõi nhật ký của cả hai phía để tìm bắt tay mới. Sau đó thử nhánh thất bại: ứng dụng khách làm gì nếu không thể hoàn tất đàm phán lại. Một đường hầm sụp sạch sẽ dễ chẩn đoán hơn một đường hầm tiếp tục gửi vào một phiên đã chết.

Đừng đọc một luồng truyền lớn thành công như bằng chứng về một ngưỡng mật mã. Nó chỉ cho thấy đường truyền và các bộ đếm đã chịu được ngần ấy lưu lượng.

Ghi lại cả hai lựa chọn

Bản ghi cần hai dòng: các gói tin được bảo vệ thế nào, và khi nào sự bảo vệ đó được thay thế. Hãy thêm thẩm quyền cho từng giá trị, vì mã hóa có thể đến từ mặc định của bản phân phối trong khi bộ hẹn giờ đến từ chính sách nội bộ. Một người vận hành trong tương lai không nên phải suy ra cả hai từ một tệp cấu hình.

Nếu khả năng tương thích buộc phải có ngoại lệ, hãy giới hạn nó trong một phiên bản và một ngày kết thúc. Một ngoại lệ sống lâu hơn lý do của nó sẽ trở thành chính sách mà không ai nhớ là đã chọn.