Tại sao thêm opt-verify không khắc phục lỗi mật mã của OpenVPN

Bạn tìm thấy một gợi ý thêm opt-verify, thêm dòng đó, và lỗi mật mã vẫn nằm đúng chỗ cũ. Kết quả đó có thể đoán trước, vì tùy chọn chưa bao giờ thương lượng một loại mật mã nào. Đó là kiểm tra tính nhất quán của tùy chọn, bị ngừng dùng trong 2.6 và bị loại bỏ trong 2.7, và một hồ sơ vẫn được phân tích với nó thì không vì thế mà áp đặt được gì.

Sẽ hữu ích khi biết dòng đó trước đây làm gì trước khi kết luận rằng nó là phần còn thiếu. Lịch sử cũng giải thích vì sao hiện tại nó không thể giúp được.

Tùy chọn trước đây áp đặt điều gì

Hướng dẫn của 2.6 đánh dấu opt-verify là không còn dùng nữa và mô tả hành vi trước đây: máy chủ loại bỏ những máy khách có tùy chọn khai báo không khớp với tùy chọn của mình, so sánh những thứ như loại thiết bị và MTU. Việc kiểm tra đó cũng phụ thuộc vào việc kiểm tra tính nhất quán tùy chọn vẫn được bật, nên một máy chủ chạy với disable-occ chưa bao giờ có nó. Hãy để ý việc so sánh được xây từ gì: văn bản mô tả cấu hình của phía bên kia. Nó không nói gì về việc kênh dữ liệu sẽ dùng mật mã nào.

Đây là lý do đầu tiên khiến cờ này không thể sửa một lỗi mật mã. Việc chọn mật mã do chính sách data-ciphers và những gì cả hai bên hỗ trợ quyết định, còn kiểm tra tính nhất quán bằng văn bản không mở rộng danh sách đó cũng không thực hiện thương lượng. Lý do thứ hai là phạm vi: kiểm tra nói về việc các tùy chọn khai báo có vẻ tương thích hay không, chứ không phải chất lượng của đường đi tạo ra.

2.7 làm gì khi thấy dòng đó

Trong 2.7 tùy chọn không còn nữa. Bộ phân tích vẫn nhận ra tên, đó là lý do một hồ sơ cũ tải được mà không có lỗi cú pháp, và nó báo rằng tùy chọn đã bị loại bỏ thay vì lặng lẽ bỏ qua. Nhận ra một cái tên và áp đặt một hành vi là hai việc khác nhau, và hiện chỉ việc đầu còn xảy ra. Ghi chú loại bỏ nêu lý do: một khi các tham số có thể thương lượng, hai bên có thể hợp pháp giữ chuỗi tùy chọn khác nhau trong khi vẫn đồng ý về kết nối.

Vì vậy một hồ sơ được phân tích không phải bằng chứng rằng có bất kỳ kiểm tra chấp nhận nào đã chạy. Nếu tín hiệu duy nhất của bạn là máy khách đã kết nối, bạn đã biết rằng cú pháp được chấp nhận.

Lỗi thực sự nằm ở đâu

Hãy giữ lại lỗi cụ thể đầu tiên trước khi thay đổi bất cứ điều gì, vì các thông báo sau thường là hậu quả của nó. Một lỗi thương lượng kênh dữ liệu thuộc về chính sách mật mã đã được phê duyệt và những khả năng mà cả hai bên thực sự công bố. Một lỗi phiên bản hoặc bộ TLS thuộc về kênh điều khiển. Việc từ chối chứng chỉ cần danh tính và chuỗi tin cậy, không phải một cờ tương thích.

Cũng hãy xác định công cụ ở cả hai đầu. Một ứng dụng máy tính để bàn có thể đóng gói bản dựng khác với tệp nhị phân dòng lệnh mà bạn đã kiểm tra, và hỗ trợ tùy chọn khác nhau giữa chúng. Hãy xem tài liệu của công cụ đó thay vì cho rằng mọi chương trình nhập hồ sơ đều hành xử như nhau.

Thay thế ý định, không chỉ dòng lệnh

Nếu một máy chủ được quản lý cũ thực sự dựa vào kiểm tra tính nhất quán, hãy ghi lại nó đã áp đặt ràng buộc nào trước khi nâng cấp. Giữ một tùy chọn bị bỏ qua trong hồ sơ mới hơn không thể bảo toàn chính sách đó, và xóa dòng một cách bừa bãi cũng không thể.

Đừng trả lời một gợi ý cũ rằng mọi mật mã đều bị vô hiệu hóa bằng cách bật mọi thuật toán lịch sử.

Sau một bản sửa đã được phê duyệt, hãy kiểm tra kết quả thương lượng trên một kết nối mới và thử ứng dụng mà người dùng thực sự cần. Giữ phiên bản máy chủ và chính sách hiệu lực bên cạnh kết quả đó, để người tiếp theo thấy điều gì đã được thống nhất chứ không chỉ điều gì đã được chấp nhận.

Mục tiêu là một ràng buộc được hỗ trợ và một đường đi đã xác thực hoạt động được, không phải một cờ cũ vẫn còn được phân tích.