Phiên bản TLS không hợp lệ của AnyConnect trên Linux: hãy xác định phạm vi sửa trước

Lỗi này xuất hiện trước khi hỏi mật khẩu, và đó là phần hữu ích: chưa có gì được xác thực, nên thông tin đăng nhập không phải vấn đề. Trên Linux, cùng một hộp thoại AnyConnect có thể đến từ một phiên bản giao thức cũ, một nhóm trao đổi khóa 1024 bit, hoặc một bộ mã hóa mà chính sách mật mã của hệ thống từ chối. Tôi đã loại bỏ nó theo ba cách khác nhau trên ba máy, và điều phân biệt các cách đó là phạm vi ảnh hưởng chứ không phải sự khéo léo. Mỗi cách đều hợp lý ở đúng chỗ và là mặc định tồi ở mọi chỗ khác.

Đọc thông báo trước khi chạm vào chính sách

Giữ nguyên chuỗi chính xác từ hộp thoại. Phàn nàn về phiên bản chỉ vào tầng giao thức, phàn nàn về chứng chỉ chỉ vào tin cậy hoặc đặt tên, và đăng nhập thất bại chỉ vào thông tin đăng nhập. Một cổng kết nối cung cấp TLS 1.0 với nhóm DHE 1024 bit, AES-256-CBC và chữ ký SHA-1 có thể có chứng chỉ hoàn toàn hợp lệ và vẫn bị chính sách hiện đại từ chối trước khi thông tin của bạn được gửi đi.

Kiểm tra điểm cuối bằng OpenSSL của hệ thống, dùng tên máy chủ thật và cổng mà ứng dụng khách sử dụng.

Nếu openssl s_client -connect vpn.example.com:443 -servername vpn.example.com thất bại trong khi -tls1 -cipher DEFAULT@SECLEVEL=0 thành công, ranh giới là phiên bản và kích thước khóa cùng lúc. Nếu lệnh đầu báo một khóa DH nhỏ thay vì cảnh báo giao thức, phiên bản ổn và chỉ nhóm cần chú ý. Không bao giờ đặt khóa riêng hay mật khẩu vào bước kiểm tra.

Tùy chọn 1: nới lỏng toàn bộ máy chủ bằng chính sách mật mã

Trên Fedora và RHEL 8 và 9, update-crypto-policies --set LEGACY hạ chính sách hệ thống của OpenSSL, và update-crypto-policies --show xác nhận cái gì đang hoạt động. Việc này thường khôi phục đường hầm, nhưng chính sách được đọc khi tiến trình khởi động, nên hãy khởi động lại ứng dụng khách và mọi tiến trình phụ mà nó tạo ra trước khi kiểm tra lại. Nó cũng cho phép giao thức cũ và nhóm yếu hơn cho mọi ứng dụng khách TLS trên máy, từ trình duyệt ở cửa sổ bên cạnh đến trình quản lý gói cập nhật nhân.

Độ rộng đó chính là toàn bộ mục đích và toàn bộ vấn đề. LEGACY áp dụng cho toàn bộ máy chủ, tồn tại lâu và dễ quên, nên nó phải là một bước chẩn đoán hoặc một ngoại lệ được ghi lại trên bản dựng được quản lý, không bao giờ là trạng thái nghỉ của máy trạm. Tôi từng thấy một máy nằm ở LEGACY suốt hai năm vì một cổng nội bộ cần nó, và không ai nói được nó bắt đầu từ khi nào.

Debian và Ubuntu không có một công tắc duy nhất cho việc này. Tương đương là sửa /etc/ssl/openssl.cnf để đặt MinProtocol thấp hơn và CipherString = DEFAULT@SECLEVEL=0 trong phần mặc định hệ thống. Cùng phạm vi, khác tệp, dễ mất dấu hơn một chút khi nâng cấp bản phát hành.

Tùy chọn 2: một tệp cấu hình cho một ứng dụng khách

Cấu hình OpenSSL theo tiến trình giữ thay đổi trong một cây tiến trình, nhưng chỉ khi tệp được nối đúng như thư viện mong đợi. Đặt tên một phần ssl_conf là chưa đủ: OpenSSL đọc khóa cấp cao nhất openssl_conf, theo nó đến một phần khởi tạo, và chỉ khi đó mới tới các mặc định của SSL.

openssl_conf = openssl_init

[openssl_init]
ssl_conf = ssl_sect

[ssl_sect]
system_default = system_default_sect

[system_default_sect]
MinProtocol = TLSv1.0
CipherString = DEFAULT@SECLEVEL=0

Trỏ OPENSSL_CONF vào tệp đó và khởi chạy ứng dụng khách VPN qua một trình bao xuất nó. Mọi thứ khác trên máy chủ giữ chính sách mặc định, và đó là thuộc tính quan trọng khi câu hỏi tuân thủ xuất hiện. Xác nhận tệp thực sự có hiệu lực trước khi đổ lỗi cho cổng kết nối: OPENSSL_CONF=/path/to/file openssl ciphers -s -tls1 phải liệt kê các mã hóa TLS 1.0, và kết quả rỗng nghĩa là chuỗi bị đứt và ứng dụng khách đã âm thầm giữ mặc định của hệ thống.

Tệp nhạy cảm với phiên bản. OpenSSL 1.1.1 và 3.x chấp nhận cùng tên phần, nhưng cách xử lý chỉ thị quanh nhà cung cấp đã thay đổi ở 3.x, nên hãy xác minh bằng nhật ký của chính ứng dụng khách và một bắt tay thử nghiệm thay vì cho rằng tệp đã được đọc. Một lỗi đánh máy trong tên phần sẽ thất bại công khai, và ứng dụng khách lặng lẽ dùng mặc định của hệ thống.

Giới hạn là độ phủ. Bất cứ thứ gì liên kết với GnuTLS hoặc NSS đều bỏ qua OPENSSL_CONF, và mọi tiến trình phụ mà ứng dụng khách khởi chạy mà không kế thừa môi trường cũng vậy. Kiểm tra bằng ldd xem tệp nhị phân thực sự liên kết với thư viện TLS nào trước khi dựng trình bao, vì câu trả lời quyết định tùy chọn này có tồn tại hay không.

Tùy chọn 3: một VM hoặc container dùng một lần

Với một nhà thầu trong hai tuần chỉ tấn công một cổng cũ, một VM riêng với chính sách nới lỏng là ranh giới sạch hơn máy trạm. Bề mặt cũ và hồ sơ duyệt web hằng ngày không còn chia sẻ chính sách nhân, và việc loại bỏ là xóa chứ không phải một phát hiện kiểm toán.

Nó vẫn là một máy nối mạng, nên hãy hạn chế truy cập và giữ nó ngoài việc duyệt web chung. Chi phí bảo trì là thêm một ảnh cần vá, điều này có thật nhưng hữu hạn và nhìn thấy được, khác với một cờ LEGACY bị quên trên laptop.

So sánh để lại gì cho bạn

Chọn theo ba câu hỏi: ai cần giao thức cũ, trong bao lâu, và ai sẽ nhận ra nếu ngoại lệ sống lâu hơn lý do của nó. Một ứng dụng, một người, vài ngày chỉ về cấu hình theo tiến trình. Cả một đội xe sau một thiết bị chỉ về chính cổng kết nối. Bất cứ thứ gì cần chính sách LEGACY thường trực trên máy chủ là một quyết định mua sắm khoác áo kỹ thuật.

Bản sửa bền vững thuộc về thiết bị: TLS 1.2 trở lên, một nhóm ít nhất 2048 bit, một mật mã AEAD và một chứng chỉ có chữ ký hiện đại. Hãy đề nghị chủ thiết bị thay đổi đó, rồi xác nhận phiên bản và mật mã đã thương lượng trong nhật ký của ứng dụng khách. Ghi lại ngoại lệ cùng máy chủ, cổng kết nối, giao thức đã thương lượng, người phê duyệt và ngày hết hạn, vì chính ghi chú đó ngăn một cách xử lý tạm thời trở thành mặc định.