OCSP CRL-ის წინააღმდეგ: როგორ მუშაობს სინამდვილეში თითოეული გაუქმების შემოწმება

ამ ორი გაუქმების შემოწმებიდან ერთი ერთი სერტიფიკატის შესახებ ხელმოწერილ პასუხს აბრუნებს, მეორე კი ხელმოწერილ სიას, რომელსაც მთლიანად ჩამოტვირთავთ. ორივეს მიზანია მამოწმებელს უთხრას, სანდოა თუ არა რწმუნება ჯერ კიდევ, და ორივე ისე ფუჭდება, რომ ერთმანეთს საერთოდ არ ჰგავს. ქვემოთ მოცემული თანმიმდევრობა მიჰყვება იმას, რასაც ოპერატორი წარმოებაში რეალურად ხვდება — ხაზზე მდებარე ბაიტებიდან დაწყებული დაკავშირების მომწყვეტი კარიბჭით დამთავრებული. ნაბიჯის გამოტოვება სწორედ ის გზაა, რომლითაც განლაგება რჩება გაუქმების იმ პოლიტიკით, რომელიც მხოლოდ ქაღალდზე არსებობს.

ნაბიჯი 1: რას აბრუნებს თითოეული შემოწმება და რამდენ ხანს რჩება გამოსადეგი

CRL ქვეყნდება როგორც ერთი ხელმოწერილი ობიექტი, რომელიც ფარავს გამომცემლის მიერ გაუქმებულ ყველა სერტიფიკატს, ამიტომ მამოწმებელი მას ერთხელ იღებს და ხელახლა იყენებს, სანამ სიის nextUpdate არ გავა. OCSP პასუხი უფრო ვიწროა: პასუხობს ზუსტად ერთ სერტიფიკატზე და ატარებს thisUpdate, producedAt და ჩვეულებრივ nextUpdate-საც. ეს განსხვავება წარმართავს ყველაფერს. ქეშირებული CRL ჩუმად ძველდება, რადგან ფაილი კვლავ იწერება და მისი ხელმოწერა კვლავ მოწმდება, ხოლო ვადაგასული OCSP პასუხი აშკარად უსარგებლოა იმ წუთას, როცა მის დროის ნიშნებს კითხულობთ.

ამიტომ ქეშირება პირველია, რაც უნდა დაფიქსირდეს: რომელი კომპონენტი ინახავს ასლს და რომელ ზედა ზღვარს ემორჩილება ეს ასლი. კარიბჭეზე ზღვარი უნდა იყოს nextUpdate-ს გამოკლებული უსაფრთხოების ზღვარი, არასოდეს ის, რასაც HTTP ქეშის სათაური შემთხვევით გვთავაზობს. openssl crl -in issuer.crl -noout -lastupdate -nextupdate ბეჭდავს ორივე თარიღს, და სია, რომლის nextUpdate უკვე წარსულშია, უნდა ჩაითვალოს არარსებულად და არა უბრალოდ ძველად.

ნაბიჯი 2: საით მიუთითებს სერტიფიკატი კლიენტს

ფოთლის სერტიფიკატი ჩვეულებრივ ორ მინიშნებას ატარებს: CRL განაწილების წერტილის გაფართოებას და OCSP-ისთვის ორგანოს ინფორმაციაზე წვდომის ჩანაწერს. openssl x509 -in client.pem -noout -ext crlDistributionPoints ბეჭდავს პირველს, ხოლო მეორე openssl x509 -in client.pem -noout -text-ის AIA განყოფილებაშია. ორივე გაფართოება მაჩვენებელია და არა ვალდებულება. კლიენტი, რომელიც არასოდეს ახორციელებს გაუქმების შემოწმებას, სრულებით კარგად დაუკავშირდება სერტიფიკატს, რომლის გაფართოებები ასახელებს ერთი წლის მკვდარ პასუხისმგებელს.

განაწილების წერტილები ხშირად ასახელებენ შიდა ჰოსტს, რომელიც მხოლოდ ერთი ქსელური სეგმენტის შიგნით წყდება, და ზოგი ძველი კლიენტი ldap URL-ებს საერთოდ უარყოფს. ხელმისაწვდომობა შეამოწმეთ იმ ჰოსტიდან, რომელიც თუნელს ამთავრებს, და არა საკუთარი ლეპტოპიდან, რადგან ეს ერთადერთი თვალსაზრისია, რომლის მარცხსაც ნამდვილად აქვს მნიშვნელობა.

ნაბიჯი 3: შეწყვეტამდე აირჩიეთ fail-closed ან fail-open

მიუწვდომელი პასუხისმგებელი ან ვადაგასული სია გადაწყვეტილებას გვაიძულებს: უარვყოთ დაკავშირება, ან მივიღოთ და ჩავწეროთ ხარვეზი. OpenSSL-ის verify ქვებრძანება მკაცრ არჩევანს გამოხატულს ხდის, რადგან -crl_check-ის დამატება მიუწვდომელ CRL-ს აქცევს unable to get certificate CRL-ად და წარუმატებელ შემოწმებად. რბილი მარცხი უმეტეს სტეკში საერთოდ არ არის დროშა, არამედ შემოწმების არარსებობა, და სწორედ ამიტომ ხვდება ის შემთხვევით წარმოებაში.

რომ ნახოთ, რა ქცევა აქვს კლიენტს სინამდვილეში, მოხსენით პასუხისმგებელი და ხელახლა დაუკავშირდით. თუ თუნელი მაინც ადის, იპოვეთ ჟურნალის ის ხაზი, რომელმაც გამოტოვებული შემოწმება ჩაწერა, და შემდეგ ჰკითხეთ, წაიკითხავდა თუ არა ვინმე ამ ხაზს ინციდენტის დროს. ერთი და იგივე მომწოდებელი შეიძლება პროტოკოლის მიხედვით განსხვავდებოდეს: ერთსა და იმავე მანქანაზე IKEv2 კლიენტი და OpenVPN კლიენტი უკავშირო კონფიგურაციის ღილაკებს კითხულობენ.

ნაბიჯი 4: დაამტკიცეთ, რომ შემოწმება მუშაობს იქ, სადაც ტრაფიკი დაიშვება

იპოვეთ პროცესი, რომელიც ამთავრებს ან ავტორიზებას უკეთებს დაკავშირებას, და შემდეგ ჰკითხეთ მას კონფიგურაციის ის ხაზი, რომელიც გაუქმების შემოწმებას რთავს. კარიბჭე, რომელიც ამოწმებს ჯაჭვს, მაგრამ არასოდეს ეკითხება გაუქმებაზე, თქვენს დოკუმენტაციაში მოცემულისგან განსხვავებულ პოლიტიკას იყენებს, და სერტიფიკატების ჯაჭვის არც ერთი ეკრანის სურათი საპირისპიროს არ ამტკიცებს. OpenVPN ამ ოპციას crl-verify-ად წერს; strongSwan CRL-ისა და OCSP-ის ძიებებს CA კონფიგურაციის ქვეშ ინახავს, სადაც crl_uris ან ocsp_uris დგინდება. თუ ვერ მიუთითებთ არც ერთზე, ჩათვალეთ, რომ შემოწმება არ არსებობს.

OCSP პასუხი ძალაშია მხოლოდ მაშინ, როცა ის გამომცემელმა CA-მ ხელი მოაწერა, ან როცა ხელი მოაწერა პასუხისმგებელმა, რომელსაც ამ CA-ის მიერ დელეგირებული OCSPSigning გაფართოებული გასაღების გამოყენება აქვს, ამიტომ უკავშირო სერვისისგან მიღებული პასუხი არაფერს ამტკიცებს. თუ თავად უმასპინძლებთ პასუხისმგებელს, დააკვირდით მას როგორც მკაცრ დამოკიდებულებას, რადგან ერთი მკვდარი სერვისი ერთდროულად ხდება შეწყვეტა ყოველი fail-closed კლიენტისთვის.

ნაბიჯი 5: განზრახ გააუქმეთ ერთი სერტიფიკატი

აიღეთ საცდელი სერტიფიკატი, გააუქმეთ იმავე არხით, რომელსაც წარმოება იყენებს, და პირდაპირ ჰკითხეთ პასუხისმგებელს. openssl ocsp -issuer ca.pem -cert old.pem -url http://ocsp.example.net -resp_text-მა უნდა მოგვახსენოს Cert Status: revoked გაუქმების დროსთან ერთად, ხოლო good პასუხი ნიშნავს, რომ თქვენი გაუქმება იმ პასუხისმგებელს არ მიუღწევია, რომელსაც თქვენი კლიენტები ეკითხებიან. შემდეგ გაუშვით openssl verify -crl_check -CRLfile issuer.crl -CAfile ca.pem old.pem, რომ იგივე გადაწყვეტილება სიის გზით ნახოთ. წაიკითხეთ მიზეზის სტრიქონი და არა გასვლის კოდი, რადგან გაუქმების უარი და ჯაჭვის შეცდომა ორივე მარცხით მთავრდება.

ნაბიჯი, რომელსაც ნამდვილად აქვს მნიშვნელობა, უკანასკნელია: ხელახლა დაუკავშირდით ძველი პროფილით რეალურ აღსრულების წერტილს და დაადასტურეთ, რომ უარი გაუქმებიდან მოდის. შემდეგ ხელახლა დაუკავშირდით ახალი, ვალიდური სერტიფიკატით, რათა დაამტკიცოთ, რომ მხოლოდ მსმენელი არ გატეხეთ. პროფილის წაშლა კლიენტზე არაფერს ამტკიცებს სერვერის გადაწყვეტილებაზე, და არც წარმატებული openssl verify გაშვება მანქანაზე, რომელიც არასოდეს ამთავრებს თუნელს. RFC 6960 განსაზღვრავს, რას შეიცავს შესაბამისი OCSP პასუხი, მათ შორის სტატუსის იმ მნიშვნელობებს, რომლებსაც ეს ტესტი კითხულობს.