OpenVPN username-as-common-name: რატომ არის თქვენი CN შემოწმება ცარიელი
client-connect სკრიპტი, რომელიც common_name-ს username-ს ადარებს, შეიძლება სახელს თავის თავს შეადაროს. მიაბით სერტიფიკატი ანგარიშს, სანამ ჩანაცვლება შესრულდება.
თქვენ ამატებთ client-connect სკრიპტს, რომელიც უარყოფს ყველა ისეთ კავშირს, სადაც common_name განსხვავდება username-სგან, და ეს სერტიფიკატისა და ანგარიშის დაკავშირებას ჰგავს. სერვერზე, რომელზეც username-as-common-name მუშაობს, ამ შედარებამ უკვე დაკარგა აზრი სკრიპტის გაშვების მომენტისთვის. ორივე მნიშვნელობა ერთი და იგივე სტრიქონია, ამიტომ ტესტი გადის სრულიად სხვა ადამიანისთვის გაცემულ სერტიფიკატზეც.
შემოწმება არ არის მცდარი იმიტომ, რომ სკრიპტი ცუდად არის დაწერილი. ის მცდარია იმიტომ, რომ მის მიერ წაკითხული მნიშვნელობა იმავე კავშირში ადრე შეიცვალა.
რას თითქოს ამტკიცებს შედარება
სერტიფიკატით ავთენტიფიკაცია და პაროლით ავთენტიფიკაცია ცალკე მტკიცებულებებია, და სერვერს შეუძლია ორივე მოითხოვოს ისე, რომ არ მოითხოვოს მათი ერთსა და იმავე პიროვნებას კუთვნილება. უფსკრული რეალურია: მოქმედი მოწყობილობის სერტიფიკატი პლუს ნებისმიერი მოქმედი ანგარიში სხვა მტკიცებაა, ვიდრე იგივე სერტიფიკატი პლუს ერთი დასახელებული ანგარიში. სკრიპტი, რომელიც common_name-ს username-ს ადარებს, ორივეს შორის დაკარგული რგოლივით იკითხება. ასეც იქნებოდა, თუ common_name ჯერ კიდევ ნიშნავდა იმას, რასაც სერტიფიკატი ამბობდა.
ასეა თუ არა, დამოკიდებულია სერვერის ერთ პარამეტრზე, და ეს პარამეტრი ჩვეულებრივ ჩაირთვება დაუკავშირებელი მიზეზის გამო, მაგალითად იმისთვის, რომ თითო მომხმარებლის კონფიგურაციის ფაილებს სახელები უფრო ადვილად დაერქვას.
რას აკეთებს username-as-common-name სახელთან
როცა username-as-common-name ჩართულია, OpenVPN მომხმარებლის სახელისა და პაროლის შემოწმების შემდეგ სერტიფიკატის საერთო სახელს ანაცვლებს ავთენტიფიცირებული მომხმარებლის სახელით. შემოწმების დროს მოქმედი შემოწმების კაკალი კვლავ იღებს სერტიფიკატის საერთო სახელს, რადგან ჩანაცვლება ჯერ არ მომხდარა. ყველაფერი შემდგომი, client-connect-ის ჩათვლით, ხედავს მომხმარებლის სახელს. ასე რომ, გვიანი გამოძახება ერთ იდენტობას ორჯერ იღებს და ვერ ადარებს მას წარმოდგენილ სერტიფიკატს.
| Stage | What common_name holds |
|---|---|
| Username and password verification hook | The certificate common name, for example bob-device |
| After the replacement | The authenticated account, alice |
| client-connect callback | The account again, alice |
მიჰყევით ერთ საილუსტრაციო კავშირს: bob-device-ისთვის გაცემული სერტიფიკატი, წარმატებული დირექტორიაში შესვლა როგორც alice, და ჩართული პარამეტრი. შემოწმების ეტაპი ჯერ კიდევ ხედავს ორ სხვადასხვა სტრიქონს. კავშირის ეტაპი ხედავს alice-ს და alice-ს.
ეს მაგალითი გვიჩვენებს, რატომ არის შედარება ცარიელი. ის არ გვიჩვენებს, რომ კავშირი სხვაგვარად მიიღებოდა, რადგან სერტიფიკატის ვალიდაცია და პაროლის შემოწმება კვლავ დამოუკიდებლად მუშაობს.
მოათავსეთ კავშირი იქ, სადაც ორივე იდენტობა ჯერ კიდევ არსებობს
წესი უნდა აღსრულდეს იმ ეტაპზე, რომელიც ერთდროულად ხედავს სერტიფიკატის იდენტობას და ანგარიშს, რაც პრაქტიკაში ნიშნავს მომხმარებლის სახელისა და პაროლის შემოწმების კაკალს ან იქ ჩატვირთულ დანამატს. მხარდაჭერილი დანამატი, რომელიც უკვე ასრულებს პაროლის შემოწმებას, ჩვეულებრივ სწორი ადგილია წყვილის წესის დასამატებლად, რადგან მისი სახელის შედარებით ჩანაცვლება მთლიანად წაშლის პაროლის შემოწმებას.
განსაზღვრეთ დაკავშირება კოდის დაწერამდე, რადგან თანასწორობა იშვიათად არის ნამდვილი პოლიტიკა. სერტიფიკატი ხშირად იდენტიფიცირებს მოწყობილობას, ხოლო შესვლა — ადამიანს, და ერთი მოწყობილობა შეიძლება ლეგიტიმურად ემსახუროს რამდენიმე ადამიანს. შეინახეთ კავშირი იმ ფორმით, რომლის გაცემასაც თქვენ აკონტროლებთ, და გადაწყვიტეთ, რა ხდება სახელის შეცვლისას, ხელახალი გაცემისას და დომენით კვალიფიცირებულ სახელებზე. პატარა ასოებად გადაქცევამ ან დომენის პრეფიქსის მოცილებამ დირექტორიის გაგების გარეშე შეიძლება გააერთიანოს ორი ანგარიში, რომლებიც ცალკე უნდა დარჩენილიყო.
გახსოვდეთ, რომ პარამეტრი ასევე ცვლის, თუ რომელი კლიენტისეული კონფიგურაცია ვრცელდება, რადგან client-config-dir საერთო სახელით არის განსაზღვრული.
გამოსცადეთ წყვილის წესი ორი მოქმედი ავტორიზაციის მონაცემით
დაიწყეთ იმ წყვილით, რომელსაც თქვენი პოლიტიკა უშვებს, და დაადასტურეთ, რომ ის უკავშირდება. შემდეგ წარმოადგინეთ იგივე მოქმედი სერტიფიკატი სხვა, მაგრამ სხვაგვარად მოქმედ ანგარიშთან: ეს ცდა უნდა ჩავარდეს, და ის უნდა ჩავარდეს წყვილის წესის გამო და არა არასწორად აკრეფილი პაროლის გამო. არასწორი პაროლი ამტკიცებს, რომ პაროლის შემოწმება მუშაობს, და არაფერს ამბობს სერტიფიკატსა და ანგარიშს შორის წესზე.
შეამოწმეთ ასევე სერტიფიკატის არარსებობისა და არამოქმედი სერტიფიკატის გზები, და დაადასტურეთ, რომელ იდენტობას იყენებს სერვერი კლიენტისეული პარამეტრებისთვის. თუ შედარების მუშაობის ერთადერთი გზა username-as-common-name-ის გამორთვაა, ჯერ შეაფასეთ ამ ცვლილების ღირებულება, რადგან ის თითო კლიენტის კონფიგურაციის ძიებას სერტიფიკატის სახელს უბრუნებს.