შეიძლება RSA სერტიფიკატი მუშაობდეს dh none-ით OpenVPN-ში?

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

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

რატომ ჩანს ორი პარამეტრი დაკავშირებული

OpenVPN-ის ძველი კონფიგურაცია ითხოვდა DH პარამეტრების ფაილს, რადგან სასრული ველის Diffie-Hellman-ს სჭირდება დომენის პარამეტრები, რომლებზეც ორივე მხარე თანხმდება. dh დირექტივა მიუთითებდა ამ ფაილზე. როცა განლაგება გადადის ECDH-ზე, პარამეტრები ნაცვლად დასახელებული მრუდიდან მოდის, და ფაილი აღარ არის საჭირო, რასაც dh none გამოხატავს.

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

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

TLS 1.2 პაკეტის სახელის სწორად წაკითხვა

აიღეთ ECDHE-RSA-AES256-GCM-SHA384. პირველი ტოკენი გასაღების გაცვლის ოჯახია: დროებითი ელიფსურ-მრუდიანი Diffie-Hellman. მეორე ავთენტიფიკაციის ოჯახია: RSA. დანარჩენი აღწერს ჩანაწერების დაცვას და ხელის ჩამორთმევაში გამოყენებულ ჰეშს.

ECDHE-ECDSA პაკეტი იყენებს იმავე გასაღების გაცვლის ოჯახს სხვა ავთენტიფიკაციის მეთოდით, ამიტომ მას სჭირდება ელიფსური მრუდის სერტიფიკატი. DHE-RSA პაკეტი იყენებს სასრული ველის დროებით Diffie-Hellman-ს RSA ავთენტიფიკაციით, და ამას ნამდვილად სჭირდება DH პარამეტრები.

წაიკითხეთ პაკეტის სახელი მარცხნიდან მარჯვნივ და მიანიჭეთ თითოეული ნაწილი თავის სამუშაოს. როცა ტოკენები გაიყოფა, კითხვა იცვლება «შეესაბამება ჩემი სერტიფიკატი dh none-ს»-დან «უშვებს ჩემი სერვერი პაკეტს, რომლის გასაღების გაცვლას DH ფაილი არ სჭირდება»-მდე.

რას თიშავს სინამდვილეში dh none

dh none ეუბნება სერვერს, რომ არ ჩატვირთოს სასრული ველის DH პარამეტრების ფაილი. ის არ თიშავს ავთენტიფიკაციას, სერტიფიკატების ვალიდაციას ან თავად TLS-ს. თუმცა ის მოითხოვს, რომ შეთანხმებული გასაღების გაცვლა იყოს ისეთი, რომელსაც ეს პარამეტრები არ სჭირდება, რაც პრაქტიკაში ნიშნავს ECDHE პაკეტს ან TLS 1.3 ხელის ჩამორთმევას.

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

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

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

მოლაპარაკების დადასტურება რედაქტირებამდე

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

თუ ის აჩვენებს TLS 1.2-ს ECDHE-RSA პაკეტით და RSA სერტიფიკატით, კომბინაცია ზუსტად ის არის, რასაც dh none ელოდება, და გამოსასწორებელი არაფერია. თუ ის აჩვენებს DHE პაკეტს ან ხელის ჩამორთმევის ჩავარდნას საერთო შიფრის გარეშე, გამოსწორება შიფრების პოლიტიკაში ან კლიენტის შესაძლებლობებშია, არა სერტიფიკატში.

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

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

ჩამონათვალის შემოწმება: RSA-ა სერტიფიკატი, დაშვებულია თუ არა ECDHE პაკეტი, აჩვენებს თუ არა ჟურნალი ამ პაკეტს, და ეთანხმება თუ არა მას ყველაზე ძველი მხარდაჭერილი კლიენტიც? თუ ოთხივე პასუხი კია, dh none თავის საქმეს აკეთებს.