Một peer cũ buộc dùng TLS 1.0: giới hạn ngoại lệ, không phải toàn bộ máy chủ

Một thiết bị cũ xuất hiện, không kết nối được, và cách sửa trông nhanh nhất là làm yếu toàn bộ máy chủ cho đến khi kết nối thành công. Sự đánh đổi đó vô hình ngay lúc đó và vĩnh viễn trên thực tế, vì không ai gỡ bỏ mức sàn cuối cùng đã hoạt động. Hai lỗi rất khác nhau tạo ra áp lực, và chỉ một trong số đó liên quan đến mật mã. Hãy phân loại lỗi trước, rồi đặt ngoại lệ ở nơi nó không thể lan ra.

Tách lỗi thành hai trước khi sửa một chỉ thị

Dòng nhật ký máy chủ về việc không có mật mã chung, hoặc về phiên bản giao thức không được hỗ trợ, đến từ kênh điều khiển: hai đầu không thống nhất được cách bảo vệ chính quá trình thương lượng. Dòng của máy khách nói rằng không có phương thức xác minh chứng chỉ máy chủ nào được bật đến từ một nơi hoàn toàn khác, vì máy khách đó thậm chí không kiểm tra ai đã trả lời. Đổi mật mã dữ liệu không giúp gì cho trường hợp thứ hai, và thêm kiểm tra vai trò không giúp gì cho trường hợp thứ nhất.

Hãy lấy dòng lỗi sớm nhất của mỗi bên thay vì dòng cuối cùng trước khi ngắt kết nối, vì dòng cuối thường chỉ là hệ quả. Sau đó xác định máy khách thực sự đã mở tệp nào: hồ sơ đã nhập thường tồn tại hai lần dưới các tên hiển thị khác nhau, và việc sửa bản sao mà không ai đọc tạo ra một sự không thay đổi đầy thuyết phục. Tiến trình đang chạy giữ các thiết lập lúc khởi động, nên tệp đã lưu không phải tệp đã nạp. Các lệnh dưới đây trình bày thương lượng của máy khách bên cạnh góc nhìn của máy chủ về cùng một lần thử.

openvpn --config <profile>.ovpn --verb 4 2>&1 | head -n 40
journalctl -u [email protected] --since '-10 min' | grep -iE 'cipher|tls|verify'

Một trình lắng nghe thứ hai là nơi trung thực cho mức sàn yếu hơn

Khi thiết bị dừng ở TLS 1.0 với kênh dữ liệu trước 2.5, máy chủ phải cung cấp mức sàn thấp hơn cho kênh điều khiển và một mật mã dữ liệu mà máy khách cũ nhận ra. Chỉ thị dự phòng tồn tại chính xác cho peer đó, trong khi danh sách mật mã giữ máy khách hiện đại trên các bộ hiện đại. Cả hai chỉ thị thuộc về trình lắng nghe chứ không phải người dùng hay kết nối, và không tùy chọn riêng cho từng máy khách nào thu hẹp chúng về sau. Đó là lý do một thiết bị cũ trên cổng chính là quyết định về mọi peer dùng chung cổng đó.

Ở nơi nền tảng cho phép, hãy chạy trình lắng nghe cũ như một thực thể riêng trên một cổng riêng, chỉ cho phép cổng đó từ địa chỉ của thiết bị, và để dịch vụ chính yên. Ghi lại lý do tồn tại của trình lắng nghe thứ hai, trong tệp chứa cấu hình của nó, vì nếu không một lần dọn dẹp sau này sẽ đọc nó như phần thừa. Việc tách chỉ đáng giá nếu mức sàn yếu hơn kết thúc ở nơi thiết bị kết thúc.

tls-version-min 1.0
data-ciphers AES-128-GCM:AES-256-GCM:AES-256-CBC
data-ciphers-fallback AES-256-CBC

Chứng chỉ nhà cung cấp cũ thực sự phá vỡ điều gì

Lỗi xác minh là một ràng buộc vai trò bị thiếu: không có nó, máy khách chấp nhận mọi chứng chỉ nối chuỗi tới một CA tin cậy, bất kể chứng chỉ đó được cấp cho máy chủ hay không. Trước tiên hãy ràng buộc chứng chỉ với vai trò máy chủ, và coi ràng buộc đó là yêu cầu chứ không phải nút tinh chỉnh. Chỉ một hồ sơ vẫn thất bại sau bước đó mới có vấn đề chứng chỉ thực sự.

Một chứng chỉ nhà cung cấp cũ mà kích thước khóa hoặc thuật toán chữ ký không còn đáp ứng chính sách mặc định của OpenSSL là trường hợp cần thay đổi mức bảo mật có phạm vi trên kênh điều khiển. Hạ mức ở đó không tắt xác minh, và tuyệt đối không được kết hợp với CA rỗng, xác minh bị tắt hoặc tên máy chủ chưa kiểm tra. Giữ dòng đó trong đúng một hồ sơ cần nó; xuất cấu hình OpenSSL đã nới lỏng ra toàn cục sẽ trao sự nới lỏng đó cho mọi chương trình trên máy.

remote-cert-tls server
tls-cipher "DEFAULT:@SECLEVEL=0"

Đọc các giá trị đã thương lượng, không phải biểu ngữ

Ở verbosity 4, cả hai đầu in ra phiên bản TLS và mật mã của kênh điều khiển mà chúng đã đồng ý, và mật mã dữ liệu của phiên. Hãy đọc những dòng đó thay vì biểu ngữ khởi tạo, vốn báo cáo thành công chứ không báo các điều kiện của nó. Sau đó kết nối lại một máy khách hiện đại với trình lắng nghe chính và xác nhận nó vẫn rơi vào một bộ hiện đại, vì một ngoại lệ rò rỉ vào cấu hình chia sẻ sẽ xuất hiện ở đây trước tiên. Các giá trị bạn sao chép sẽ thành nền tảng cho lần rà soát tiếp theo.

Hãy thử thiết bị cũ một mình: nó phải kết nối được, và nó phải là phiên duy nhất trong nhật ký hiển thị các tham số yếu hơn. Nếu một peer thứ hai cũng thương lượng bộ cũ, ngoại lệ rộng hơn dự định và việc tách trình lắng nghe đã không thực sự xảy ra. Ghi lại cả hai quan sát chứ không chỉ kết luận.

Mọi ngoại lệ đều cần một người sở hữu và một ngày

Một ngoại lệ không có điều kiện gỡ bỏ sẽ lặng lẽ trở thành mặc định, nên hãy đặt thiết bị, người sở hữu, lý do và ngày nó biến mất bên cạnh cấu hình mà nó biện minh. Không có dòng đó, mức sàn yếu hơn sẽ sống lâu hơn phần cứng đã cần nó.

Thay máy khách, hoặc yêu cầu nhà cung cấp một hồ sơ hiện hành, là kết quả cần hướng tới; ngoại lệ là một sự trì hoãn chứ không phải thiết kế. Khi thiết bị nghỉ hưu, hãy gỡ trình lắng nghe và hồ sơ trong cùng một thay đổi để không nửa nào tiếp tục chạy. Không điều gì trong số này làm các tham số cũ an toàn, nó chỉ ngăn giới hạn của một thiết bị trở thành nền tảng của mọi người.