SSTP და SSL 3.0: ეტიკეტი მოლაპარაკებული ვერსიის წინააღმდეგ

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

ორი პასუხი ერთ კითხვაზე

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

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

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

წაიკითხეთ ვერსია, რომელსაც სერვისი რეალურად ირჩევს

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

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com </dev/null> | grep -E 'Protocol|Cipher'
Get-WinEvent -LogName System -ProviderName Schannel -MaxEvents 20

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

გამოყავით ჩანაწერის ველი მოლაპარაკებისგან

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

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

ამიტომ „ამ დატვირთვის გამოყენება ალბათ რთულია“ არ არის არგუმენტი SSL 3.0-ის ჩართული დატოვების სასარგებლოდ. მოთხოვნაა პროტოკოლის წაშლა და არა ერთ დემონსტრაციაზე კამათის მოგება.

გააუქმეთ SSL 3.0 ისეთი პოლიტიკით, რომელსაც დაიცავთ

Windows-ში Schannel-ის პროტოკოლის პარამეტრები Protocols გასაღების ქვეშაა და ცალ-ცალკე იკითხება კლიენტისა და სერვერის როლისთვის, ამიტომ ერთი მიმართულების გამასწორებელ ცვლილებას შეუძლია მეორე ხელუხლებელი დატოვოს. მიმდინარე პარამეტრები და მათი გადატვირთვის მოთხოვნები Microsoft-ს აქვს დოკუმენტირებული, და იმავე ჰოსტზე მესამე მხარის TLS ბიბლიოთეკა მათ სრულიად უგულებელყოფს.

Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server'
Get-ChildItem 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols'

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

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

მიიღეთ ცვლილება ახალი კავშირებით

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

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

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