რა ხდება, როცა VPN-ის სერტიფიკატის ორგანოს ცვლით

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

ერთი ჩანაცვლება, ორი ცალკე ცვლილება

სერტიფიკატის ორგანო არის სახელი, საჯარო გასაღები და ხელმომწერი კერძო გასაღები. ვალიდატორები არასდროს ენდობიან „CA-ს“ აბსტრაქტულად. ისინი ენდობიან ერთ კონკრეტულ სერტიფიკატს, რომელიც უკვე ზის ნდობის საცავში, და გამომცემელს მხოლოდ მაშინ იღებენ, როცა ხელმოწერათა ჯაჭვი იმ შენახულ ასლს აღწევს. ამიტომ CA-ს შეცვლა ცვლის ორ რამეს, რომლებიც ერთმანეთისგან დამოუკიდებლად ფუჭდება: რომელი ღუზები მიიღება და რომელი პარტნიორის იდენტობა გაიცა მათ ქვეშ.

VPN-ის განთავსებების უმეტესობა ორივე მიმართულებით ამოწმებს. კლიენტი ავთენტიფიცირებს კარიბჭის სერტიფიკატს, კარიბჭე კი კლიენტისას. გადართვა, რომელიც მხოლოდ კლიენტის პაკეტს აახლებს, სერვერს ტოვებს, რომ უარყოს ყველა კლიენტი, რომელიც ჯერ კიდევ ძველი CA-ს იდენტობას წარადგენს, და საპირისპირო ისეთივე ჩვეულებრივია. ჯერ ჩამოთვალეთ აღსრულების წერტილები: კლიენტების ნდობის საცავები, კარიბჭის ca ფაილი, მის წინ TLS-ს დამამთავრებელი ნებისმიერი პროქსი და გარედან ბოლო წერტილის შემმოწმებელი ზონდი.

რას ამოწმებს ვალიდატორი, თანმიმდევრობით

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

ამ ბილიკის ოფლაინ გასამეორებლად მიმართეთ -CAfile ზუსტად იმ პაკეტს, რომელსაც განათავსებთ და არა სისტემის საცავს. წინააღმდეგ შემთხვევაში ამოწმებთ ჰოსტს და არა ცვლილებას:

openssl verify -CAfile new-ca.crt gateway.crt
openssl verify -CAfile new-ca.crt -untrusted intermediate.crt client.crt
openssl x509 -in gateway.crt -noout -subject -issuer -dates
openssl s_client -connect gw.example.net:443 -CAfile new-ca.crt

ეს ბრძანება მუშაობს მხოლოდ ჩვეულებრივი TLS მსმენელის წინააღმდეგ, როგორიც კარიბჭის HTTPS ადმინისტრირების გვერდია; OpenVPN-ის საკონტროლო არხი TLS-ს წინ უსწრებს, ამიტომ s_client გვირაბის ხელისჩამკეტს ვერ შეამოწმებს.

იმ შეცდომების მიღმა მდგარი ბილიკის აგების წესებია RFC 5280 მე-6 ნაწილი იქ. ისინი ხსნიან წარუმატებლობებს, რომლებიც სხვაგვარად თვითნებურად გამოიყურება: ვადაგასული შუალედური, რომელიც არავის ახსოვდა, სერტიფიკატი, რომლის გასაღების გამოყენება ხელმოწერას კრძალავს, ან სახელის შეზღუდვა, რომელიც თქვენ მიერ შესამოწმებელ ჰოსტს გამორიცხავს.

რატომ აგრძელებს ძველი გვირაბი მუშაობას

TLS და OpenVPN ორივე ცოცხლად ინახავს დამყარებულ სესიას ხელისჩამკეტის დასრულების შემდეგ. არაფერი ამოწმებს პარტნიორის სერტიფიკატს თითოეულ პაკეტზე, ამიტომ ცვლილებამდე დაკავშირებული კლიენტი აგრძელებს ტრაფიკის გატარებას, სანამ ხელახლა არ მოილაპარაკებს, ხელახლა არ დაუკავშირდება ან გვირაბი არ ჩამოვარდება. სწორედ ეს ნაპრალი იწვევს იმას, რომ CA-ს შეცვლა საათობით შეიძლება კარგად გამოიყურებოდეს და შემდეგ ყველაზე ცუდ მომენტში ჩავარდეს: ლეპტოპი ძილიდან იღვიძებს, NAT-ის დაკავშირება იწურება, კარიბჭე გადაიტვირთება.

სესიის განახლება უფრო აჭიმავს ილუზიას. TLS სესიის ბილეთი კლიენტს საშუალებას აძლევს დაბრუნდეს სერტიფიკატების ხელახლა გაგზავნის გარეშე, ხოლო განახლება გამოტოვებს ბილიკის ვალიდაციას, რადგან პირველმა ხელისჩამკეტმა უკვე გააკეთა ის. ამიტომ პატიოსანი გამოცდა ახალ პროცესში სრული ხელისჩამკეტია. გადატვირთეთ კლიენტი გვირაბის ხელახლა დაკავშირების ნაცვლად, და სატესტო პროფილზე განიხილეთ ბილეთების გამორთვა, რომ განახლების ბილიკმა გატეხილი ჯაჭვი ვერ დამალოს.

სტატიკური გასაღების შრე ამისგან ცალკე შეინახეთ. tls-auth საკონტროლო არხს HMAC-ს უმატებს, tls-crypt მას შიფრავს და ავთენტიფიცირებს, და არც ერთი მათგანი სერტიფიკატის მასალას არ ატარებს, ამიტომ რომელიმეს ბრუნვა ცალკე ცვლილებაა საკუთარი ჩავარდნის რეჟიმით. განთავსებები, რომლებიც ორივეს ურევს, ისეთ კლიენტამდე მიდიან, რომლის სტატიკური გასაღები რიგზეა, სერტიფიკატი მოძველებულია და შეცდომის შეტყობინება არც ერთს ახსენებს.

სუბიექტის სახელის ხელახლა გამოყენების ხაფანგი

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

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

ბრუნვა, რომელიც ქსელს არ ჩამოგდებს

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

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

გაისტუმრეთ საპირისპირო მიმართულებით. თავიდან გასცეთ ყოველი იდენტობა, რომელმაც უნდა გადარჩეს, დაადასტურეთ, რომ თითოეული ახალ ჯაჭვს წარადგენს, შემდეგ კი პაკეტებიდან ძველი ღუზა მოხსენით. ძველი CA-ს კერძო გასაღები მოაცილეთ სამსახურიდან, რადგან ჯერ კიდევ ხელმომწერი გამომცემელი ნიშნავს, რომ ბრუნვა არ დასრულებულა. სერტიფიკატები და გაცემის ჩანაწერები აუდიტისთვის შეინახეთ. დაკარგული გამომცემელი იმავე ნდობას უბრუნდება; გამჟღავნება კი ახალ იდენტობებს მოითხოვს და ძველ ღუზაზე დაბრუნება აღარ შეიძლება.

შედეგი შეამოწმეთ და არა ფაილების სია

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

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

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