OpenVPN: EC và ED — vì sao những cái tên này không phải một thang bậc sức mạnh

Đặt ec, ed, ecdh, ecdsa, auth và một danh sách mật mã TLS cạnh nhau trong cùng một tệp cấu hình, và tệp bắt đầu trông như một núm chỉnh sức mạnh với sáu nấc. Không phải vậy. Mỗi cái tên trả lời một câu hỏi khác nhau, và hai cấu hình chỉ khác nhau ở một trong số đó không nhất thiết cái này mạnh hơn hay yếu hơn cái kia. Sắp xếp các cái tên theo công việc chúng đảm nhận mất khoảng năm phút và ngăn được phần lớn những chỉnh sửa tồi mà người ta hay làm trên một cấu hình đang chạy tốt.

Phần sắp xếp dưới đây bắt đầu từ chính sự nhầm lẫn, rồi mở dần ra những phần của cấu hình thực sự quyết định điều gì bảo vệ lưu lượng của bạn. Mỗi mục lần lượt lấy một cách đọc sai và chỉ ra cái tên thực sự gắn với điều gì.

Hai chữ cái, hai câu hỏi khác nhau

Cặp gây tranh cãi nhiều nhất là EC và ED, và cuộc tranh luận thường cho rằng chúng là những câu trả lời đối thủ cho cùng một câu hỏi. Chúng thậm chí không nằm trên cùng một trục. EC mô tả một họ toán học: mật mã đường cong elliptic, nơi độ an toàn đến từ độ khó của bài toán logarit rời rạc trên một đường cong chứ không phải trong một trường hữu hạn lớn.

ED mô tả một dạng đường cong bên trong họ đó. Các đường cong Edwards xoắn là một cách biểu diễn được chọn vì tốc độ và vì khả năng chống lại một số sai sót khi triển khai, và Ed25519 là cái tên người ta thường muốn nói tới. Đường cong này không phải đối thủ của mật mã đường cong elliptic; nó là một cách viết một đường cong elliptic. Đọc ED thành “EC mới hơn, mạnh hơn” là ngã rẽ sai đầu tiên, và mọi thứ sau đó thường sai theo cùng một hướng.

Ký và trao đổi khóa là hai công việc tách biệt

Khi câu hỏi về họ đã rõ, những cái tên còn lại tách thành hai cột không bao giờ thay thế nhau. Một cột ký, cột kia thống nhất một bí mật chung.

EdDSA và ECDSA đều ký, nhưng chúng là những lược đồ khác nhau với định dạng khóa khác nhau, nên chứng chỉ cấp cho lược đồ này không dùng được như lược đồ kia. EdDSA được định nghĩa cho một tập đường cong nhỏ; P-256 không thuộc tập đó, đó là lý do chứng chỉ P-256 xác minh bằng ECDSA và không bao giờ bằng Ed25519.

Cột trao đổi không có thứ tương đương nào tên là EdDH. Thỏa thuận tạm thời trên một khóa Curve25519 là X25519, và đó là ECDH với một đường cong cụ thể, đúng như với P-256. Ed25519 đúng nghĩa chỉ là lược đồ chữ ký, dù cái tên được dùng lỏng lẻo cho cả việc trao đổi vì hai đường cong có liên hệ: dạng Edwards dùng để ký và dạng Montgomery dùng cho X25519 mô tả cùng một nhóm nền.

Vì sao một cấu hình EC không có tệp dh

Một tệp dh chứa các tham số được tạo sẵn cho Diffie-Hellman trên trường hữu hạn, và những tham số đó tồn tại vì một số nguyên tố lớn và một phần tử sinh phải đến từ đâu đó. Trao đổi trên đường cong elliptic không cần chúng: đường cong có tên chính là bộ tham số, và cả hai bên đều đã biết nó. Đó là toàn bộ lý do một cấu hình EC có thể bỏ qua chỉ thị này.

Hai tình huống vẫn tạo ra một dòng dh trong một cấu hình mà ngoài ra trông có vẻ hiện đại. Thứ nhất là một trình lắng nghe thứ hai hoặc một đối tác cũ hơn thực sự thương lượng các nhóm trường hữu hạn. Thứ hai là đoạn văn bản sót lại chép từ một mẫu thời RSA và chưa bao giờ bị xóa. Một cấu hình đặt tên đường cong cho việc trao đổi mà vẫn nạp một tệp dh 2048-bit thì không an toàn hơn vì đã làm thế; nó chỉ đang mang theo một thứ không dùng đến.

TLS 1.3 đã bỏ trao đổi khóa khỏi cái tên

So sánh TLS_AES_256_GCM_SHA384 với TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384 và cái tên ngắn hơn trông như một sự hạ cấp. Đó là một lần đổi tên, và lý do mang tính cấu trúc: TLS 1.3 đã loại bỏ RSA tĩnh và trao đổi khóa Diffie-Hellman trên trường hữu hạn, nên trao đổi đường cong elliptic tạm thời là lựa chọn phi PSK duy nhất còn lại. Ghi nó vào mọi bộ mật mã sẽ lặp lại cùng một sự thật cả chục lần.

Loại chứng chỉ biến mất khỏi cái tên vì một lý do liên quan. Trong 1.3, chứng chỉ xác thực chữ ký của quá trình bắt tay, không phải thỏa thuận khóa, nên nó không còn chọn bộ mật mã. Đó cũng là lý do trong cấu hình tồn tại một danh sách mật mã riêng cho 1.3: các bộ mật mã được đổi tên và sắp xếp lại, chứ không bị làm yếu đi.

Một hệ quả đáng nói thẳng. ECDHE là một thuật toán trao đổi khóa và không bao giờ là mật mã. Một bộ mật mã được mô tả là “elliptic” nói về cách hai bên đi đến một khóa chung, và không nói gì cả về việc sau đó cái gì mã hóa phần dữ liệu.

auth xác thực gói tin, không phải dữ liệu

Chỉ thị auth chọn bản băm HMAC dùng để xác thực gói tin, và giá trị mặc định lịch sử của nó là SHA1. Với một mật mã dữ liệu không phải AEAD, OpenVPN tính bản băm trên bản mã rồi nối thêm vào, một cách sắp xếp mã hóa trước rồi MAC sau, và chính điều đó khiến việc thao túng phần đệm trở nên không thực tế.

Ngộ nhận ở đây là nâng auth lên SHA512 sẽ làm đường hầm vững hơn. Điều đó không làm tăng độ mạnh của mã hóa, và nếu mật mã dữ liệu được thương lượng là một chế độ AEAD như AES-256-GCM, thì bản băm hoàn toàn không được áp lên các gói dữ liệu. Thẻ GCM đã xác thực chúng rồi, và giá trị auth được để dành cho HMAC của kênh điều khiển và cho bất kỳ mật mã không phải AEAD nào còn dùng.

Vậy chỉ thị này có quan trọng, nhưng nó quan trọng ở một chỗ hẹp hơn vị trí của nó trong tệp gợi ý. Kiểm tra xem thực tế đã thương lượng mật mã nào sẽ cho bạn biết nó có được áp dụng hay không.

Đọc cấu hình theo cột, không theo thứ hạng

Ba câu hỏi tách các lớp ra một cách gọn gàng, và mỗi câu được trả lời bởi một phần khác nhau của phiên đã thương lượng. Mật mã nào bảo vệ phần dữ liệu? Thẻ hay bản băm nào bảo chứng cho từng gói, và mật mã đang dùng có cần đến nó không? Chứng chỉ của ai đã khép lại quá trình bắt tay, và kênh điều khiển có được bảo vệ thêm bằng tls-auth hay tls-crypt không?

Không có gì trong nhãn EC hay ED quyết định bất kỳ điều nào trong ba điều đó, và chỉ riêng tên một bộ mật mã cũng không quyết định được điều nào. Kết quả đã thương lượng là bằng chứng duy nhất, nên hãy đọc nó thay vì suy ra sức mạnh từ từ vựng:

openssl x509 -in client.crt -noout -text | grep -E 'Signature Algorithm|Public Key Algorithm'
grep -i 'control channel' /var/log/openvpn.log

Lệnh đầu tiên cho bạn biết chứng chỉ của bạn thực sự dùng lược đồ chữ ký nào, và đó là cách đáng tin cậy duy nhất để biết bạn đang chạy ECDSA hay Ed25519. Lệnh thứ hai hiển thị dòng kênh điều khiển mà ứng dụng khách đã ghi vào nhật ký cho phiên, bao gồm phiên bản TLS và bộ mật mã mà nó đã chọn. Nếu một chỉnh sửa cấu hình không thể biện minh bằng một trong hai đầu ra đó, thì nhiều khả năng đó là thay đổi về cái tên chứ không phải về một thuộc tính.