OpenVPN საკონტროლო პაკეტების კვლევა: tls-auth TLS-ამდე

tls-auth-ის წარუმატებლობა ჩვეულებრივ ხელის ჩამორთმევის პრობლემად მოიხსენიება, თუმცა არასოდეს ყოფილა ასეთი. HMAC მოწმდება საკონტროლო პაკეტზე ნებისმიერი TLS დამუშავების დაწყებამდე, ამიტომ შეუსაბამო გასაღები ან მიმართულება წარმოქმნის ხარვეზს, რომელიც სერტიფიკატის პრობლემას ჰგავს და ორი ფენით ადრე წყდება. კონვერტის, როგორც ცალკე ობიექტის, განხილვა დიაგნოზს ამოკლებს: წაიკითხეთ ველები, დაადასტურეთ, რომ შემოწმება ადრე ერთვება, შემდეგ შეადარეთ ის სამი რამ, რაზეც ორივე მხარე უნდა შეთანხმდეს.

წაიკითხეთ კონვერტი იმ თანმიმდევრობით, რომლითაც იგი იგება

საკონტროლო პაკეტი ატარებს სესიის იდენტიფიკატორს, არასავალდებულო tls-auth HMAC-ს, გამეორებისა და დადასტურების ინფორმაციას და სანდო შეტყობინების იდენტიფიკატორს, ხოლო შემდეგ მოდის შეტყობინების ტიპის დატვირთვა. როცა შეტყობინება ხელის ჩამორთმევის შეტყობინებაა, დატვირთვა შემთხვევით TLS დაშიფრული ტექსტია. ეს არის მთელი კავშირი: TLS მასალა მოძრაობს შეტყობინების შიგნით, რომელსაც კონვერტი უკვე იცავს. იხილეთ OpenVPN ქსელური პროტოკოლის ცნობარი რომელიც ჩამოთვლის საკონტროლო არხის ველებს ამ თანმიმდევრობით.

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

შეინარჩუნეთ ეს დაჯგუფება ცნებად. ეს არ არის ბაიტების რიგის დიაგრამა და არ არის საკმარისი ტეგის გამოსათვლელად, რადგან HMAC-ში შემავალი ველები დამოკიდებულია იმპლემენტაციაზე, ვერსიასა და რეჟიმზე.

აჩვენეთ, რომ შემოწმება ხელის ჩამორთმევამდე ერთვება

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

გაზარდეთ დემონის სიტყვიერება და დააკვირდით საკონტროლო არხს და არა tun მოწყობილობას:

openvpn --config /etc/openvpn/server.conf --verb 6

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

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

შეათანხმეთ გასაღები, მიმართულება და digest ორივე მხარეს

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

grep -E 'tls-auth|tls-crypt|key-direction|auth ' /etc/openvpn/server.conf

შექმენით საერთო საიდუმლო ხელსაწყოთი და არა რედაქტორით, და შეინახეთ ნებართვები მკაცრად:

openvpn --genkey secret /etc/openvpn/ta.key
chmod 600 /etc/openvpn/ta.key

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

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

ტეგი მხოლოდ რეალური ფორმატიდან აღადგინეთ

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

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

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

დააბრუნეთ შეუსაბამობა დაცვის მოხსნის გარეშე

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

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

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