Cụm mật khẩu trên khóa riêng VPN thực sự bảo vệ điều gì

Lời nhắc xuất hiện khi ứng dụng VPN khởi động rất dễ đọc sai. Đó không phải mật khẩu tài khoản VPN, không phải mật khẩu của đường hầm, và việc nhập nó không chứng minh kết nối an toàn. Nó mở khóa một biểu diễn được lưu của khóa riêng để ứng dụng có thể đọc vật liệu khóa và dùng nó để xác thực. Mọi thứ xảy ra sau đó là một câu hỏi khác.

Trong thực tế, câu trả lời sai ở các mép: người ta cho rằng cụm mật khẩu bảo vệ đường hầm đang chạy, hoặc việc thay đổi nó thu hồi một bản sao của khóa đã rò rỉ. Cả hai giả định đều sai, và cả hai đều sai theo cách để lộ thông tin xác thực trong khi người vận hành tin rằng đã xử lý xong.

Một hộp thoại, nhiều bí mật khác nhau

Cụm mật khẩu của khóa riêng giải mã một tệp. Mật khẩu tài khoản xác thực bạn với một dịch vụ. Mật khẩu nhập PKCS#12 giải mã một gói chứa khóa và chứng chỉ của nó, và có thể không phải cùng một chuỗi với cụm mật khẩu của chính khóa. Những lời nhắc này có thể trông gần như giống hệt nhau, và việc đoán bí mật nào đi đâu là cách khóa bị dán vào sai trường.

Mã hóa của chính đường hầm là điều thứ tư. Kênh dữ liệu dùng khóa phiên được thương lượng trong quá trình bắt tay; cụm mật khẩu của khóa riêng không có vai trò gì trong việc bảo vệ từng gói. Nếu ai đó đọc được tệp khóa, họ có thể thử đoán cụm mật khẩu ngoại tuyến, nhưng nếu họ đọc được gói, cụm mật khẩu là không liên quan.

Mã hóa trên đĩa bao gồm những gì

Khóa PEM được mã hóa có hai dạng, và tiêu đề cho bạn biết bạn có dạng nào. Dạng PKCS#8 hiện đại bắt đầu bằng -----BEGIN ENCRYPTED PRIVATE KEY-----; dạng PEM cũ, vẫn phổ biến trong các thiết lập OpenVPN cũ, bắt đầu bằng -----BEGIN RSA PRIVATE KEY----- và mang Proc-Type: 4,ENCRYPTED cùng một dòng DEK-Info ngay bên dưới. Tệp lưu khóa riêng được mã hóa dưới một khóa dẫn xuất từ cụm mật khẩu của bạn, thường qua KDF dựa trên mật khẩu với số vòng lặp hoặc hệ số công việc được nêu. Tài liệu OpenSSL pkey bao gồm các định dạng và tùy chọn cụm mật khẩu áp dụng khi đọc.

Hai hệ quả theo sau. Cụm mật khẩu yếu có thể bị tấn công ngoại tuyến với tốc độ mà KDF cho phép, vì vậy quyền tệp và quyền truy cập bản sao lưu vẫn quan trọng ngay cả khi tệp được mã hóa. Và kẻ tấn công chỉ lấy được tệp mà không có cụm mật khẩu phải đoán; người lấy được cả tệp và cụm mật khẩu có khóa, đúng như thể nó chưa từng bị mã hóa.

head -3 vpn.key
openssl pkey -in vpn.key -noout -pubout
openssl pkcs12 -in bundle.p12 -info -noout

head -3 hiển thị tiêu đề và, trên tệp cũ, các dòng Proc-Type và DEK-Info chứng minh mã hóa; một dòng đơn lẻ không là bằng chứng theo hướng nào. Dòng pkey hỏi cụm mật khẩu và chỉ in nửa công khai, điều này chứng minh tệp và cụm mật khẩu hoạt động mà không lộ khóa riêng. Không dùng -text cho kiểm tra đó: nó in các thành phần riêng tư, privateExponent, prime1, prime2 và phần còn lại, và đầu ra đó không bao giờ được dán ở đâu, không trong phiếu, trò chuyện hay nhật ký. Lệnh PKCS#12 cũng cho bạn biết gói có mật khẩu MAC hoặc mã hóa riêng hay không, điều đáng biết trước khi đưa nó cho đồng nghiệp.

Điều gì nó ngừng bảo vệ sau khi khóa được tải

Mở khóa là sự kiện một chiều đối với tiến trình đó. Ứng dụng yêu cầu KDF cấp khóa, giải mã tệp và giữ khóa riêng trong bộ nhớ chừng nào cần. Từ thời điểm đó, cụm mật khẩu không bảo vệ gì về phiên đang chạy: không phải bộ nhớ tiến trình, không phải kết xuất nhân, không phải phiên gỡ lỗi gắn với ứng dụng, và không phải bản sao lưu của máy được lấy trong khi khóa đang dùng.

Đây là cùng ranh giới với khóa SSH có cụm mật khẩu, hoặc kho đã mở khóa của trình quản lý mật khẩu. Nó làm tăng chi phí đánh cắp tệp khi nằm yên và không làm gì chống lại phần mềm độc hại chạy dưới người dùng của bạn, ứng dụng được ủy quyền yêu cầu ứng dụng ký, hoặc quản trị viên có thể đọc bộ nhớ. Hãy coi nó là một lớp, không phải cơ chế kiểm soát khiến khóa an toàn khi bỏ mặc.

Tại sao lời nhắc cứ quay lại

Ứng dụng hỏi lại mỗi lần kết nối lại không nhất thiết bị hỏng. Một số ứng dụng lưu cụm mật khẩu vào bộ nhớ đệm cho phiên, số khác lưu trong chuỗi khóa của hệ điều hành, và số khác có thể được trỏ đến một trình trợ giúp cung cấp nó, vì vậy hành vi bạn nhận được phụ thuộc vào ứng dụng và cấu hình của nó, không phải tệp khóa.

Nếu lời nhắc lặp lại là khiếu nại thực sự, hãy xem các tùy chọn lưu đệm và xác thực của ứng dụng trước khi gỡ mã hóa khỏi khóa. Gỡ cụm mật khẩu biến tệp được bảo vệ thành khóa văn bản thuần, và việc kết nối lại trở nên im lặng với cái giá là cơ chế kiểm soát khi nằm yên duy nhất bạn có. Câu trả lời tốt hơn thường là kho thông tin xác thực được hỗ trợ với cùng quyền tệp mà bạn vẫn dùng.

Mất và lộ không phải là cùng một cách sửa

Cụm mật khẩu bị mất không thể khôi phục từ chứng chỉ. Chứng chỉ là vật liệu công khai liên kết tên với khóa; nó không chứa đường quay lại khóa riêng và không có gợi ý về cụm mật khẩu. Các lựa chọn thực tế là bản sao lưu được ủy quyền của khóa, hoặc danh tính mới được cấp qua quy trình bình thường của người vận hành. Bất kỳ ai đề nghị 'khôi phục' cụm mật khẩu đều đang đề nghị đoán nó.

Lộ cần phản ứng khác. Mã hóa lại cùng khóa với cụm mật khẩu mới giữ nguyên vật liệu khóa, vì vậy bản sao đã được mở khóa ở nơi khác vẫn hoạt động. Cách sửa là thu hồi hoặc thay thế thông tin xác thực: cấp khóa và chứng chỉ mới, phân phối chúng, và loại bỏ cái cũ ở đối tác. Cho đến khi điều đó xảy ra, đổi mật khẩu tệp là việc nhà, không phải ngăn chặn. Chỉ giữ tệp cũ ra khỏi bản sao lưu sau khi xác nhận danh tính mới hoạt động, và ghi lại số sê-ri hoặc dấu vân tay nào đã thay thế nó.