OpenVPN tls-ciphersuites tls-version-min-ის წინააღმდეგ: რას ავალდებულებს თითოეული
TLS 1.3 სუიტების სია პროტოკოლის ვერსიას არ ზღუდავს, ხოლო show-tls მხოლოდ ლოკალურ მხარდაჭერას აჩვენებს. დამოუკიდებლად შეამოწმეთ პოლიტიკა, სუიტები და შეთანხმებული შედეგები.
სამი განსხვავებული ფაქტი ერთ ხაზში იკუმშება OpenVPN TLS-ის შესახებ დისკუსიების უმეტესობაში: რა შეუძლია თქვენი კლიენტის აწყობას, რას უშვებს პროფილი და რაზე შეთანხმდა სინამდვილეში სესია. TLS 1.3-ის სუიტების მოკლე სია შუა კითხვას მხოლოდ ნახევრად პასუხობს და პროტოკოლის ვერსიის ქვედა ზღვარზე არაფერს ამბობს. გაიარეთ ქვემოთ მოცემული შემოწმებები თანმიმდევრობით და გაჩერდით პირველზე, რომელიც არ უძლებს, რადგან ყოველი შემდგომი შემოწმება ვარაუდობს, რომ წინები უკვე მოწესრიგებულია.
შეამოწმეთ აწყობა, სანამ რომელიმე სიას წაიკითხავთ
კონფიგურაციის დირექტივა ვერ დაამატებს პროტოკოლის მხარდაჭერას ბინარულ ფაილს, რომელსაც ის არ აქვს. დაიწყეთ ვერსიის ბანერით, რომელიც ასახელებს კომპილირებულ კრიპტოგრაფიულ ბიბლიოთეკას:
openvpn --version
OpenSSL-ზე მიბმული 2.6 აწყობა იღებს როგორც tls-cipher, ისე tls-ciphersuites-ს. mbed TLS-ით აწყობას საერთოდ არ აქვს TLS 1.3 სუიტების არჩევანი, და 2.6 სახელმძღვანელო tls-ciphersuites-ს OpenSSL-ის ოფციად აღნიშნავს. თუ სერვერი სხვა backend-ით ხელახლა აშენდება, იგივე პროფილმა შეიძლება შეცვალოს ქცევა კონფიგურაციის ერთი ხაზის შეცვლის გარეშეც.
სანამ აქ ხართ, გაუშვით openvpn --show-tls და შეინახეთ გამოტანილი მონაცემები. ეს არის ის ინვენტარი, რომელსაც მოგვიანებით შეადარებთ, და იაფია მისი აღება მანამ, სანამ ვინმე პროფილების რედაქტირებას დაიწყებს.
ბანერი და სია ჩაწერეთ ცვლილების ბილეთში და არა ჩატის ფანჯარაში. როცა ორი ადამიანი კამათობს, შეძლებს თუ არა კლიენტი ექვს კვირაში სუიტის შეთავაზებას, დაფიქსირებული გამონატანი ამას ერთ ხაზში წყვეტს.
ვერსიის საზღვრები შიფრების სიებისგან ცალკე შეინახეთ
2.6 სახელმძღვანელოში ეს სამი კონტროლია და არა ერთი:
tls-cipherადგენს შიფრის პოლიტიკას TLS 1.2-ისა და უფრო ძველი ვერსიებისთვის და გადაეცემა OpenSSL-ის შიფრების სიას;tls-ciphersuitesირჩევს TLS 1.3 სუიტებს;tls-version-minდაtls-version-maxზღუდავს იმ პროტოკოლის ვერსიებს, რომელთა გამოყენებაც კავშირს შეუძლია.
ამიტომ ფრთხილად მოჭრილი TLS 1.3 სუიტების სია არაფერს ამტკიცებს იმის შესახებ, რომ ძველი ვერსია ჯერ კიდევ დაშვებულია. თუ მოთხოვნაა „მხოლოდ TLS 1.3“, მას ვერსიის ქვედა ზღვარი ატარებს, და სუიტების სია მხოლოდ ამ ზღვრის შიგნით ავიწროებს არჩევანს:
tls-version-min 1.3
tls-ciphersuites TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256
ეს წყვილი ორ საქმეს აკეთებს. ერთი ხაზის წაშლა მეორეს ტოვებს იმაზე ნაკლებს ავალდებულებდეს, ვიდრე ფიქრობთ, და სწორედ ეს არის ის მარცხი, რომლის დასაჭერადაც მთელი ეს შემოწმება არსებობს.
მონაცემთა არხი მეოთხე კონტროლია. data-ciphers აწარმოებს მოლაპარაკებას გვირაბის შიგნით სიმეტრიულ შიფრზე, და მისი შედეგი არაფერს ამბობს საკონტროლო არხის TLS ვერსიაზე. AES-256-GCM-ის დანახვა სესიის შეჯამებაში არ არის TLS 1.3-ის მტკიცებულება არც ერთი მიმართულებით.
show-tls წაიკითხეთ როგორც ლოკალური ინვენტარი
--show-tls ჩამოთვლის იმ სუიტებს, რომლებსაც მხარს უჭერს ის კრიპტოგრაფიული ბიბლიოთეკა, რომელზეც ეს ბინარია მიბმული, უპირატესობის რიგით. ეს არ არის გეითვეიდან მიღებული ანგარიში. სახელმძღვანელო ცხადად ამბობს, რომ სია ლოკალური ბიბლიოთეკიდან მოდის, რაც ნიშნავს, რომ OpenSSL 3.x-იანი ლეპტოპი და უფრო ძველი აწყობის მქონე როუტერი განსხვავებულ სიებს დაბეჭდავს, სანამ ერთსა და იმავე სერვერთან საუბრობენ.
| Evidence | What it actually describes |
|---|---|
--show-tls output | Capabilities of this client build and its library |
| Profile directives | What this attempt is allowed to offer |
| Session log line | What this one negotiation selected |
დავუშვათ, კლიენტი მხარს უჭერს A, B და C სუიტებს და ერთი სესია ირჩევს B-ს. ეს არაფერს ადგენს იმის შესახებ, უშვებს თუ არა სერვერი A-ს ან C-ს, და არც იმას, არის თუ არა B მისი ერთადერთი დაშვებული არჩევანი. სამი სტრიქონი ცალკე შეინახეთ, და TLS-ის დამაბნეველი თემების უმეტესობა თავისით გადაიჭრება.
ინვენტარის შენახვა მაინც ღირს. როცა სესია ვერ ხერხდება, ბიბლიოთეკის სიის შედარება პროფილის სიასთან გიჩვენებთ, ჰქონდა თუ არა კლიენტს საერთოდ შანსი შეეთავაზებინა ის, რაც სერვერს სურდა. ის ასევე გიჩვენებთ, ჩუმად ამოიღო თუ არა backend-ის ცვლილებამ TLS_CHACHA20_POLY1305_SHA256 იმ პულიდან, რომელსაც ძველი კლიენტები ეყრდნობიან — რეგრესიის ის ტიპი, რომელიც რამდენიმე მომხმარებლის დაკავშირების წარუმატებლობად ვლინდება, სანამ ყველა დანარჩენი ვერაფერს ამჩნევს.
ჰკითხეთ გეითვეის ისეთი რამ, რაზეც მას პასუხის გაცემა შეუძლია
თუ სერვისს თქვენ მართავთ, შეამოწმეთ გაშვებული ინსტანციის ეფექტური კონფიგურაცია და არა დისკზე არსებული ფაილი. შესაძლოა OpenVPN სხვა --config ბილიკით გაშვებულიყო, ჩასმულ ფაილებს იძახებდეს და რედაქტირების შემდეგ არ გადაშვებულიყოს. გაშვებული დემონის პოლიტიკაა ის, რასაც კლიენტები ხვდებიან.
თუ მას თქვენ არ მართავთ, ოპერატორს სთხოვეთ მხარდაჭერილი კლიენტის მოთხოვნები ან შეზღუდული მიღების ტესტი. უარყოფილი მცდელობა ავტომატურად უარყოფილი სუიტა არ არის: ვერსიის ქვედა ზღვარმა, სერტიფიკატის იდენტობის შემოწმებებმა, როგორიცაა remote-cert-tls, ან tls-auth-სა და tls-crypt-ს შორის შეუსაბამობამ შეიძლება შეწყვიტოს გაცვლა მანამ, სანამ სუიტის არჩევანი მნიშვნელოვანი გახდება. წაიკითხეთ სერვერის შეცდომა, სანამ კლიენტის სიას შეცვლით, რადგან „handshake failed“ ოთხ სხვადასხვა მიზეზს მოიცავს და მათგან მხოლოდ ერთია შიფრის შეუსაბამობა.
openssl s_client-ის VPN პორტისკენ მიმართვა ასევე არ ამრავლებს კითხვას. საკონტროლო არხი OpenVPN-ის საკუთარი ჩარჩოს შიგნით მუშაობს, ამიტომ ნედლი TLS შემოწმება სხვა პროტოკოლს ამოწმებს პორტზე, რომელიც სხვა რამეს მოელის. მისგან გამოტანილი ნებისმიერი დასკვნა შემოწმებას ეხება და არა გვირაბს.
ჩაიწერეთ ორი შედეგი და ცალ-ცალკე შეინახეთ
ახალი დაშვებული სესია ქმნის საკონტროლო არხის სტრიქონს, რომელიც ასახელებს პროტოკოლის ვერსიას და არჩეულ შიფრს, და ცალკე მონაცემთა არხის სტრიქონს, რომელიც ასახელებს გვირაბის შიფრს. დააფიქსირეთ ორივე კლიენტის ვერსიასთან და პროფილის სახელთან ერთად, და ჩაინიშნეთ, რომელმა სერვერის ინსტანციამ უპასუხა:
openvpn --config office.ovpn --verb 4 2>&1 | tee session.txt
შემდეგ ეს ორი სტრიქონი წაიკითხეთ იმ ფაილიდან და არა მეხსიერებიდან. წყვილია მტკიცებულება; მხოლოდ სუიტის სახელი უპირატესობაა, და ვერსიის საზღვარი ცალკე განცხადებაა იმის შესახებ, რასაც სერვერი უარყოფს.
შეასრულეთ შემოწმებები ამ თანმიმდევრობით. დაადასტურეთ აწყობა და backend --version-ით. დააფიქსირეთ --show-tls სანამ რამეს შეცვლით. დაასახელეთ საჭირო ვერსიის ქვედა ზღვარი სუიტების სიისგან ცალკე. დაადასტურეთ გაშვებული ინსტანციის ეფექტური პოლიტიკა მის მფლობელთან. დააკვირდით ერთ დაშვებულ სესიას და, თუ გეგმა იძლევა საშუალებას, ძველი ვერსიით ერთ უარყოფილ მცდელობას. ჩაიწერეთ საკონტროლო არხისა და მონაცემთა არხის შედეგები ცალკე აღმოჩენებად.
თუ საჭირო კლიენტი ვერ აკმაყოფილებს ახალ მინიმუმს, მიიღეთ ეს მიგრაციის ან გამონაკლისის გადაწყვეტილება ცხადად, ნაცვლად იმისა, რომ ჩუმად დაწიოთ შეუსაბამო მიღების წესი, რათა გაშვება დასრულებულად გამოიყურებოდეს.