Lời nhắc khóa OpenVPN sau OpenSSL 3: kiểm tra nhà cung cấp

Không ai chạm vào hồ sơ, vậy mà cùng ứng dụng khách đó giờ đây yêu cầu cụm mật khẩu cho khóa riêng mỗi lần khởi động. Khi thay đổi đó xuất hiện trong vài ngày sau một lần nâng cấp bản phân phối, bản nâng cấp chính là nguyên nhân khả dĩ: OpenSSL 3 đã tổ chức lại phần hỗ trợ thuật toán, và một khóa mà thư viện cũ đọc trơn tru có thể trở nên không đọc được mà không một byte nào thay đổi. Hãy thực hiện các kiểm tra theo thứ tự, vì hai trong số đó trông giống hệt nhau nếu chỉ nhìn vào lời nhắc.

Câu hỏi đầu tiên là khóa có được mã hóa hay không, và câu thứ hai là bản dựng này có giải mã được nó hay không. Thay đổi cấu hình chỉ có ý nghĩa sau khi biết cả hai câu trả lời.

Kiểm tra xem khóa có được mã hóa không

Đọc dòng đầu tiên của tệp rồi để thư viện phân tích nó, vì tên tệp không chứng minh được gì. Một khối PEM có nhãn ENCRYPTED PRIVATE KEY là PKCS#8 đã mã hóa, và một khối RSA PRIVATE KEY cũ hơn mang Proc-Type: 4,ENCRYPTED là dạng truyền thống, cả hai đều chờ một cụm mật khẩu. Một khối PRIVATE KEY không mã hóa thì không nên hỏi đến nó. Chạy phân tích bằng tài khoản sở hữu tệp, vì sự cố quyền truy cập tạo ra một lỗi khác và kém thú vị hơn nhiều.

Nếu khóa thực sự không được mã hóa mà ứng dụng khách vẫn hỏi, hãy ngừng nhìn vào mật mã học và kiểm tra xem hồ sơ có nêu một tệp askpass mà dịch vụ vẫn đọc được hay không.

Kiểm tra xem bản dựng này có giải mã được nó không

OpenSSL 3 đã chia phần hỗ trợ thuật toán thành các nhà cung cấp, và một tập mật mã cũ hơn giờ nằm ở nhà cung cấp legacy thay vì nhà cung cấp mặc định. Một khóa được mã hóa bằng một trong những mật mã đó vẫn hợp lệ, nhưng một thư viện được nạp mà không có nhà cung cấp legacy thì không thể giải mã nó. Ở một số ứng dụng khách, điều đó hiện ra như một lời nhắc lặp lại, ở những ứng dụng khác như một thất bại cứng ngay sau cụm mật khẩu.

Phân tích cùng một khóa hai lần với cùng một tệp nhị phân: trước tiên chỉ với nhà cung cấp mặc định, sau đó với cả legacy và mặc định được yêu cầu trên dòng lệnh. Nếu lần thử thứ hai thành công ở nơi lần đầu thất bại, chẩn đoán dựa trên bằng chứng chứ không dựa vào thời điểm nâng cấp. Nếu cả hai đều thất bại giống nhau, cụm mật khẩu sai hoặc tệp bị hỏng, và không cài đặt nhà cung cấp nào sửa được cả hai.

Kiểm tra cách khắc phục hẹp nhất hiện có

Ưu tiên thay đổi giới hạn trong ứng dụng khách hơn là thay đổi toàn hệ thống. Một số bản dựng 2.6 chấp nhận một tùy chọn hồ sơ nạp cả hai nhà cung cấp cho tiến trình của daemon đó, nên hãy xác nhận chỉ thị trong tài liệu hướng dẫn cho đúng phiên bản của bạn trước khi dựa vào nó; thay vào đó, chỉnh sửa openssl.cnf của hệ thống sẽ ảnh hưởng đến mọi chương trình OpenSSL trên máy chủ. Cài đặt hẹp hơn cũng dễ hoàn tác hơn nhiều sau khi khóa được mã hóa lại.

Đừng xóa cụm mật khẩu để lời nhắc biến mất. Điều đó biến một thông tin xác thực được bảo vệ thành tệp văn bản thuần và âm thầm thay đổi rủi ro của mọi bản sao lưu, bản sao và gói hỗ trợ mà nó xuất hiện. Sự khác biệt quan trọng là giữa một khóa cần cụm mật khẩu của nó và một khóa mà thư viện này không thể giải mã.

Kiểm tra ngữ cảnh dịch vụ, rồi mã hóa lại

Khi khóa có thể được mở khóa, hãy mã hóa lại nó bằng một thuật toán hiện hành để sự phụ thuộc biến mất. Ghi tệp mới bằng một mật mã hiện đại, xác minh rằng nó phân tích được, cập nhật hồ sơ và chỉ giữ bản sao cũ cho đến khi một kết nối thành công. Không bao giờ đặt cụm mật khẩu trên dòng lệnh, nơi bất kỳ người dùng cục bộ nào cũng có thể đọc nó từ danh sách tiến trình. Chỉ xóa tệp cũ sau khi tệp mới đã kết nối từ tài khoản dịch vụ, chứ không chỉ từ shell của bạn.

Sau đó kiểm tra đơn vị thực sự chạy ứng dụng khách. Một khóa đọc được trong shell của bạn có thể không đọc được đối với một dịch vụ chạy dưới tài khoản khác hoặc với thiết lập thư mục nhà được tăng cường.

Ghi lại cài đặt nhà cung cấp bên cạnh hồ sơ và giữ bài kiểm tra hai lệnh cùng với nó. Khi một lần nâng cấp sau đó loại bỏ nhà cung cấp legacy, hãy chạy lại bài kiểm tra đó để xem khóa còn cần nó hay hồ sơ có thể được đưa ra khỏi giải pháp tạm thời.

Lời nhắc là một triệu chứng với ít nhất ba nguyên nhân, và chỉ một trong số đó là cụm mật khẩu bị thiếu.