auth digest bảo vệ những gói OpenVPN nào?
Tùy chọn auth bao phủ ít hơn những gì một hồ sơ gợi ý. Hãy xem xét kênh, trường hợp AEAD và bảo vệ kênh điều khiển trước khi đặt chính sách digest.
Phần lớn tranh luận về digest OpenVPN bắt đầu từ sai gói tin. Đọc auth SHA256 như “chỉ chấp nhận các peer cung cấp SHA256” là điều đầu tiên cần bỏ đi. Tùy chọn này nêu tên một digest cho những gói cụ thể, và những gói nào thì phụ thuộc vào kênh và vào việc kênh đó có phải AEAD hay không. Hãy đi qua bốn câu hỏi dưới đây theo thứ tự; mỗi câu thu hẹp ý nghĩa mà thiết lập có thể có trong triển khai của bạn.
Nêu tên kênh mà thiết lập phải bảo vệ
OpenVPN có kênh điều khiển mang lưu lượng bắt tay TLS và kênh dữ liệu mang tải trọng của tunnel. Digest auth có vai trò ở cả hai, nhưng không giống nhau, và hồ sơ hiếm khi làm cho khác biệt trở nên rõ ràng. Hãy ghi ra bạn đang cố giới hạn kênh nào trong hai kênh trước khi chạm vào tệp cấu hình.
Bảng dưới đây là phiên bản ngắn về cách cùng một tùy chọn rơi vào từng bối cảnh.
| Context | What the auth digest does |
|---|---|
| Data channel without AEAD | Selects the HMAC digest that authenticates each data packet |
| Data channel with AEAD, such as GCM | Unused for the data channel; the cipher authenticates its own packets |
| Control channel protected by tls-auth | Selects the HMAC digest for that protection, even when data is AEAD |
Kiểm tra xem kênh dữ liệu có phải AEAD trước khi dựa vào nó
Nếu mật mã dữ liệu được thương lượng là AES-GCM hoặc CHACHA20-POLY1305 thì kênh dữ liệu tự xác thực và digest riêng không làm công việc mà bạn có thể đang hình dung. Cả hai đều là cấu trúc AEAD, nên tính toàn vẹn được tạo ra bởi chính thao tác mã hóa tải trọng. Đây không phải là hạ cấp, nhưng nó có nghĩa là một chính sách được biện luận là “mọi gói dữ liệu đều là HMAC-SHA256” thực tế sai trên tunnel đó. Hãy xác nhận giá trị đã thương lượng trong nhật ký máy chủ hoặc đầu ra trạng thái của máy khách trước khi viết lại chính sách.
Hãy xem mật mã thực sự được thương lượng thay vì danh sách trong hồ sơ, vì thương lượng có thể rơi vào một thành viên khác của tập hợp. data-ciphers AES-256-GCM:AES-128-GCM là danh sách thương lượng, và cả hai mục đều là AEAD, nên không mục nào tiêu thụ digest auth để bảo vệ tải trọng.
Coi việc bảo vệ kênh điều khiển là một quyết định riêng
tls-auth thêm một HMAC vào các gói của kênh điều khiển và lấy digest của nó từ thiết lập auth, vì thế một tunnel AEAD vẫn có thể có digest có ý nghĩa được cấu hình. tls-crypt là một cách bố trí khác với lớp bảo vệ cố định riêng, nên đừng cho rằng nó thừa hưởng mọi thuộc tính của tls-auth. Hãy đọc tài liệu của cơ chế bạn đã chọn thay vì chuyển giả định giữa chúng.
Hai peer cũng phải thống nhất về cách bố trí và về hướng của khóa. Một digest khớp nhưng tệp khóa dùng sai hướng sẽ tạo ra bắt tay thất bại vì những lý do mà thiết lập digest không thể giải thích.
Giữ auth tách khỏi thương lượng mật mã và chứng chỉ
Ba thiết lập liên tục bị nhầm lẫn: digest auth, danh sách mật mã dữ liệu và thuật toán chữ ký của chứng chỉ. Thay đổi cái thứ nhất không cấp lại chứng chỉ, không chọn digest chữ ký của nó và không tạo ra phương thức người dùng-mật khẩu. Các định nghĩa tùy chọn giao thức trong mã nguồn OpenVPN 2.6 mô tả từng cái trong mục riêng, đây là lời nhắc hữu ích rằng chúng là những núm điều chỉnh độc lập.
Khi một peer từ chối kết nối sau thay đổi digest, nguyên nhân thường là sự không khớp ở một trong hai thiết lập còn lại. Hãy đọc cả hai đầu trước khi thay đổi bất kỳ cái nào.
Viết chính sách ra và so sánh với các cấu hình đang chạy
Một tuyên bố cấp đội phải nêu rõ các chế độ kênh dữ liệu được phép và lớp bảo vệ kênh điều khiển đã chọn, trong cùng một câu. Câu đó có thể kiểm chứng; “chúng tôi dùng SHA256” thì không. Sau đó hãy so sánh nó với hồ sơ máy chủ và máy khách hiệu lực thay vì với một mẫu trong kho lưu trữ.
Kết thúc bằng việc ghi lại mỗi tunnel thực sự đã thương lượng gì và cơ chế nào đã xác thực các gói của nó. Một dòng auth hiển thị trong hồ sơ chỉ là bằng chứng về ý định cấu hình, và ý định là phần rẻ nhất của việc kiểm tra.