Vì sao AES-256 không mô tả một bộ mã hóa VPN
Một bộ hoàn thành bốn vai trò: mã hóa hàng loạt, tính toàn vẹn, thiết lập khóa và xác thực đối tác. Tên của một mật mã chỉ bao trùm một trong số đó, trên một tầng.
Hỏi VPN dùng mã hóa gì và câu trả lời thường đến trong một từ: AES-256, hoặc ChaCha20, hoặc có lẽ WireGuard. Câu trả lời đó nêu tên một thành phần của một tầng, trong khi thứ thực sự bảo vệ kết nối là một tập hợp thuật toán hoàn thành bốn vai trò khác nhau. Nhầm lẫn thành phần với cách bố trí là lỗi phổ biến nhất trong những cuộc trò chuyện này, và nó tạo ra những so sánh không thể giải quyết.
Bốn việc trong một kết nối
Mã hóa hàng loạt biến văn bản rõ thành văn bản mã cho kênh dữ liệu, và khóa của nó được dẫn xuất thay vì truyền đi. Bảo vệ toàn vẹn phát hiện thay đổi, đây là một việc riêng ngay cả khi một cấu trúc làm cả hai. Thiết lập khóa tạo ra vật liệu lưu lượng chung, và xác thực đối tác quyết định ai ở đầu bên kia. Nếu thiếu bất kỳ điều nào, kết nối không an toàn, dù phần còn lại mạnh đến đâu.
Một số thiết kế gộp hai vai trò làm một. AES-GCM và ChaCha20-Poly1305 là các cấu trúc mã hóa có xác thực, nên tính bí mật và toàn vẹn đi cùng nhau; AES-CBC thì không, và cần một mã xác thực thông điệp riêng với khóa riêng. Vì vậy đọc một đề xuất như một túi số độc lập là đọc sai những thứ được thiết kế thành cặp.
Các vai trò cũng nằm ở các tầng khác nhau, nên cùng một từ có thể mang nghĩa khác trong hai sản phẩm. Mật mã khối trong ESP và mật mã khối trong TLS là cùng một nguyên thủy trong các cuộc đàm phán khác nhau với yêu cầu khác nhau. Vì vậy trích dẫn một nguyên thủy mà không có chế độ và tầng của nó có thể tệ hơn là không trích dẫn gì.
Vì sao tên một mật mã gần như không nói gì
Hãy coi cụm AES-256 một cách nghiêm túc trong giây lát: nó chỉ định một mật mã khối và một kích thước khóa. Nó không nói gì về chế độ hoạt động, liệu tính toàn vẹn có được cung cấp, khóa được thiết lập thế nào hay đối tác được xác thực ra sao. Hai sản phẩm đều có thể quảng cáo AES-256 và khác nhau ở mọi thứ còn lại, kể cả một sản phẩm ghép nó với chế độ không xác thực và một sản phẩm dùng chế độ AEAD với trao đổi khóa hiện đại.
TLS 1.3 đưa sự tách biệt này vào tiêu chuẩn, đây là một chỉnh sửa hữu ích cho bất kỳ ai học từ vựng cũ. Các bộ mật mã của nó chỉ nêu tên AEAD và hàm băm, trong khi nhóm trao đổi khóa và thuật toán chữ ký được đàm phán như những tham số riêng. Vì vậy tên bộ TLS 1.3 không thể so sánh với tên bộ TLS 1.2 trên cùng cơ sở, dù cả hai xuất hiện trong cùng một trường của tệp cấu hình. Một kiểm toán viên so sánh trực tiếp hai chuỗi sẽ đi đến kết luận mà giao thức không ủng hộ. Hãy đọc cả nhóm đã đàm phán và tham số chữ ký, nếu không so sánh sẽ không đầy đủ.
WireGuard chọn con đường ngược lại và gần như loại bỏ đàm phán: giao thức quy định một tập thuật toán cố định, nên hai triển khai hoặc tương thích hoặc không. Đây là một lựa chọn thiết kế hợp lý, và cũng có nghĩa câu hỏi WireGuard đàm phán bộ nào không có câu trả lời đáng so sánh. Nếu bạn kiểm toán nó, hãy đọc đặc tả một lần rồi kiểm toán việc quản lý khóa xung quanh nó thay vì đàm phán.
Tầng quyết định từ vựng
Một triển khai IPsec đàm phán hai lần: đề xuất IKE cho kênh điều khiển và chuyển đổi ESP cho dữ liệu, và hai thứ đó có thể khác nhau một cách hợp lệ. Đọc cái đầu và cho rằng nó mô tả cái thứ hai là nguồn nhầm lẫn phổ biến khi kiểm toán, vì tệp cấu hình đề cập cả hai và cái thú vị là cái thứ hai.
| Layer | What is negotiated there | What it does not cover |
|---|---|---|
| IKE proposal | Algorithms and groups for the control channel that builds the tunnel | The algorithms protecting the data itself |
| ESP transform | Encryption and integrity for tunneled packets | Peer identity, which authentication already settled |
| TLS handshake | AEAD and hash, plus separately negotiated groups and signatures | Routing, authorization or retention policy |
| WireGuard | Nothing; the algorithm set is fixed by the protocol | Everything above the cryptographic arrangement |
Một tên có sẵn trong một thư viện không tự động được triển khai cho một đường dữ liệu khác. Vì vậy tuyên bố sản phẩm của chúng tôi hỗ trợ AES-256 yếu hơn vẻ ngoài của nó, và vì thế vấn đề tương tác thường được giải quyết bằng cách tìm phần giao được duy trì thay vì bật mọi thuật toán cũ ở cả hai phía.
Đặc tả TLS 1.3 là ví dụ công bố rõ ràng nhất về sự tách biệt này, vì nó định nghĩa bộ như một cặp và chuyển phần còn lại sang đàm phán riêng. Khi hình dạng đó đã quen, đề xuất IPsec và tập cố định duy nhất của WireGuard được đọc như những biến thể của cùng một ý tưởng.
Đọc kết quả đã đàm phán, rồi dừng lại
Một đề xuất được cấu hình không phải bằng chứng về điều hai bên đã chọn. Phiên đang sống mang câu trả lời, và mọi triển khai phổ biến đều có thể báo cáo điều đó mà không cần bắt gói tin.
openssl s_client -connect vpn.example.net:443 -brief
ipsec statusall
wg showTrong đầu ra, hãy đọc các thuật toán được chọn thay vì danh sách được đề nghị. Nếu câu trả lời yếu hơn chính sách dự định, việc sửa nằm ở cấu hình đề xuất của một bên, và sự không khớp trong các triển khai hiện đại thường xuất hiện như một đàm phán thất bại chứ không phải hạ cấp âm thầm.
Sau đó nhớ bộ không bao trùm điều gì. Tuyến, quyền ứng dụng, ghi nhật ký và lưu trữ là những quyết định riêng với việc xem xét riêng, và một cách bố trí mật mã tương thích không nói gì về chúng. Cuộc thảo luận về mật mã đáng để có, nhưng nó trả lời một câu hỏi hẹp hơn câu hỏi mà hầu hết mọi người thực sự đặt ra.
Giữ từ vựng chính xác và lập luận ngắn lại. Một bộ là tập hợp các vai trò trên một tầng, một mật mã là một thành phần, và kết quả đã đàm phán là thứ duy nhất mô tả kết nối bạn thực sự có. Mọi thứ khác trong so sánh chỉ là trang trí.