Lỗi mật mã TLS trên OpenVPN: so sánh cả hai phía trước

Lỗi «không có mật mã chung» nghe như chỉ cần đổi một cài đặt, và cài đặt mà phần lớn mọi người đổi lại chính là cái sai. OpenVPN giữ chính sách riêng cho kênh điều khiển thực hiện bắt tay TLS và cho kênh dữ liệu chở gói tin bên trong đường hầm, và lỗi gọi tên kênh thứ nhất trong khi người ta sửa kênh thứ hai. So sánh điều mỗi phía cho phép, theo đúng thứ tự, biến phỏng đoán thành hai hoặc ba quyết định: phiên bản, rồi danh sách bộ mật mã, rồi thông tin xác thực.

Sai thứ tự đó là có thể mất một giờ để thêm một tên AES vào danh sách chưa từng được xem tới.

Hai danh sách mật mã, và chỉ một danh sách làm hỏng bắt tay

Kênh điều khiển thương lượng một phiên TLS, và chính sách của nó được viết bằng tls-cipher cho TLS 1.2 và tls-ciphersuites cho TLS 1.3. Kênh dữ liệu được cấu hình riêng bằng data-ciphers, nơi sự không khớp tạo ra kết nối được thiết lập rồi sau đó không truyền được lưu lượng. Cả hai đều sinh lỗi có nhắc tới mật mã, nên chúng bị lẫn. Một bắt tay không bao giờ hoàn tất chỉ về kênh điều khiển, còn một đường hầm đã dựng mà đánh rơi gói tin lại chỉ về kênh dữ liệu.

Đọc toàn bộ thông báo thay vì dòng đầu. Không khớp phiên bản, thiếu bộ mật mã, thuật toán chữ ký chứng chỉ mà phía kia từ chối và việc kiểm tra tên máy chủ thất bại đều kết thúc bằng lỗi TLS, và chỉ một trong số đó liên quan đến danh sách bộ mật mã của bạn. Tách các nhóm đó ra chính là phần lớn của chẩn đoán.

So sánh phiên bản trước khi so sánh bộ mật mã

Một phía giới hạn ở TLS 1.2 và một phía đòi 1.3 không chia sẻ phiên bản nào, và không chuỗi mật mã nào bắc cầu điều đó. Ghi lại tls-version-min và tls-version-max ở cả hai phía, hoặc giá trị mặc định của bản dựng đang dùng, vì chính sách OpenSSL của một bản phân phối có thể nâng mức sàn mà không tùy chọn OpenVPN nào nói ra. Nếu một phía là thiết bị hoặc ứng dụng khách bên thứ ba, cửa sổ của nó là điều phần sụn cho phép. Chỉ khi hai cửa sổ chồng lên nhau thì so sánh bộ mật mã mới có nghĩa.

Những ghi chép đó cũng nên nêu tên các tệp nhị phân thực tế. Một openvpn dòng lệnh trên máy tính xách tay của bạn không chắc là ứng dụng khách xử lý hồ sơ đã nhập.

Danh sách TLS 1.2 và TLS 1.3 không trộn lẫn

Tên bộ mật mã TLS 1.2 trông như ECDHE-RSA-AES256-GCM-SHA384 và thuộc về tls-cipher, thứ nhận một chuỗi mật mã OpenSSL. Bộ mật mã TLS 1.3 có tên như TLS_AES_256_GCM_SHA384 và thuộc về tls-ciphersuites; thêm một bộ vào chuỗi 1.2 không cấu hình danh sách 1.3, và bộ phân tích có thể nhận văn bản mà không bao giờ khớp nó. Một bộ lọc đúng cho một phiên bản không nói gì về phiên bản kia. Ghi rõ danh sách nào dành cho phiên bản nào.

openvpn --show-tls in ra những gì bản dựng cục bộ hỗ trợ, và đó là danh mục chứ không phải lời hứa: phía từ xa có thể không cho phép những bộ mật mã đó, và hồ sơ đang hoạt động có thể không bật chúng. Dùng nó để loại một bản dựng hoàn toàn không thể cung cấp bộ mật mã nào, rồi so sánh các danh sách đã cấu hình.

Chứng minh thương lượng trên một kết nối mới

Bắt tay thành công là bằng chứng duy nhất được tính, và nó phải đến từ ứng dụng khách thật với hồ sơ thật. Nâng mức chi tiết của máy chủ, kết nối một lần, và đọc từ nhật ký phiên bản giao thức cùng bộ mật mã đã thương lượng thay vì cho rằng giá trị được đề nghị đầu tiên đã thắng. Sau đó xác nhận riêng kênh dữ liệu bằng lưu lượng qua đường hầm, vì một bắt tay chạy được và một kênh dữ liệu hỏng là hai cách sửa khác nhau. Lặp lại sau mọi thay đổi cấu hình, vì hồ sơ khách cũ là nguyên nhân âm tính giả thường gặp.

Nếu không có cấu hình chung đã được phê duyệt, câu trả lời là nâng cấp hoặc một kế hoạch di trú, không phải một chính sách bị làm yếu. Hạ tls-version-min, tắt kiểm tra hoặc bật mọi bộ mật mã cũ loại bỏ sự từ chối mà không đáp ứng yêu cầu bảo mật đã sinh ra nó.

Ghi phiên bản đã thương lượng, bộ mật mã và mật mã dữ liệu vào phiếu thay đổi. Người tiếp theo gặp lỗi TLS sẽ bắt đầu từ ghi chép đó, chứ không phải từ một chuỗi mật mã tìm thấy trong bài đăng diễn đàn.