OpenVPN username-as-common-name: vì sao kiểm tra CN của bạn trống

Bạn thêm một script client-connect từ chối mọi kết nối mà common_name khác với username, và nó trông giống như một ràng buộc giữa chứng chỉ và tài khoản. Trên máy chủ chạy username-as-common-name, phép so sánh đó đã mất ý nghĩa vào lúc script chạy. Cả hai giá trị là cùng một chuỗi, nên bài kiểm tra vẫn đạt với một chứng chỉ được cấp cho một người hoàn toàn khác.

Việc kiểm tra không sai vì script được viết kém. Nó sai vì giá trị mà nó đọc đã bị thay thế trước đó trong cùng kết nối.

Phép so sánh có vẻ chứng minh điều gì

Xác thực bằng chứng chỉ và xác thực bằng mật khẩu là những bằng chứng riêng biệt, và máy chủ có thể yêu cầu cả hai mà không yêu cầu chúng thuộc cùng một người. Khoảng trống là có thật: một chứng chỉ thiết bị hợp lệ cộng với bất kỳ tài khoản hợp lệ nào là một tuyên bố khác với chính chứng chỉ đó cộng với một tài khoản được nêu tên. Một script so sánh common_name với username đọc như mắt xích còn thiếu giữa hai bên. Nó sẽ như vậy, nếu common_name vẫn mang nghĩa mà chứng chỉ đã nói.

Có như vậy hay không phụ thuộc vào một tùy chọn máy chủ, và tùy chọn đó thường được bật vì một lý do không liên quan, chẳng hạn để dễ đặt tên các tệp cấu hình cho từng người dùng.

username-as-common-name làm gì với tên

Khi username-as-common-name được bật, OpenVPN thay tên chung của chứng chỉ bằng tên người dùng đã xác thực sau khi tên người dùng và mật khẩu được xác minh. Hook xác minh chạy trong lần kiểm tra đó vẫn nhận tên chung của chứng chỉ, vì việc thay thế chưa diễn ra. Mọi thứ sau đó, kể cả client-connect, đều thấy tên người dùng. Vì vậy lệnh gọi lại sau đó nhận một danh tính hai lần và không thể so sánh nó với chứng chỉ đã trình bày.

Theo dõi một kết nối minh họa: một chứng chỉ được cấp cho bob-device, một lần đăng nhập thư mục thành công với tên alice, và tùy chọn được bật. Giai đoạn xác minh vẫn có thể thấy hai chuỗi khác nhau. Giai đoạn kết nối thấy alice và alice.

Ví dụ đó cho thấy vì sao phép so sánh trống. Nó không cho thấy kết nối sẽ được chấp nhận theo cách khác, vì việc kiểm tra chứng chỉ và xác minh mật khẩu vẫn chạy độc lập.

Đặt ràng buộc ở nơi cả hai danh tính vẫn tồn tại

Quy tắc phải được thực thi ở một giai đoạn thấy danh tính của chứng chỉ và tài khoản cùng lúc, mà trên thực tế là hook xác minh tên người dùng và mật khẩu hoặc một plugin được nạp ở đó. Một plugin được hỗ trợ đã thực hiện xác minh mật khẩu thường là nơi đúng để thêm quy tắc ghép cặp, vì thay nó bằng phép so sánh tên sẽ loại bỏ hoàn toàn việc kiểm tra mật khẩu.

Xác định ánh xạ trước khi viết mã, vì sự bằng nhau hiếm khi là chính sách thật. Chứng chỉ thường nhận diện một thiết bị trong khi đăng nhập nhận diện một người, và một thiết bị có thể phục vụ hợp pháp nhiều người. Lưu mối quan hệ ở dạng mà bạn kiểm soát việc cấp phát, và quyết định điều gì xảy ra khi đổi tên, khi cấp lại và với các tên có định danh miền. Việc chuyển sang chữ thường hoặc bỏ tiền tố miền mà không hiểu thư mục có thể hợp nhất hai tài khoản lẽ ra phải tách biệt.

Hãy nhớ rằng tùy chọn cũng thay đổi cấu hình cho từng máy khách nào được áp dụng, vì client-config-dir được khóa theo tên chung.

Kiểm tra việc ghép cặp với hai thông tin đăng nhập hợp lệ

Bắt đầu với cặp mà chính sách của bạn cho phép và xác nhận rằng nó kết nối. Sau đó trình bày cùng chứng chỉ hợp lệ đó với một tài khoản khác nhưng vẫn hợp lệ: lần thử đó phải thất bại, và nó phải thất bại vì quy tắc ghép cặp chứ không phải vì mật khẩu gõ sai. Mật khẩu sai chứng minh rằng việc kiểm tra mật khẩu hoạt động và không nói gì về quy tắc giữa chứng chỉ và tài khoản.

Cũng kiểm tra các đường đi thiếu chứng chỉ và chứng chỉ không hợp lệ, và xác nhận máy chủ dùng danh tính nào cho cài đặt từng máy khách. Nếu cách duy nhất để phép so sánh hoạt động là tắt username-as-common-name, hãy ước tính chi phí của thay đổi đó trước, vì nó đưa việc tra cứu cấu hình của mọi máy khách trở lại tên của chứng chỉ.