SSTP არის PPP HTTPS-ზე, და არა ვებგვერდი პორტ 443-ზე

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

გაიარეთ ოთხი ეტაპი თანმიმდევრობით, და თქვენს მიერ დანახული ხარვეზი ერთ-ერთ მათგანში მოხვდება.

ეტაპი 1: TCP და TLS

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

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

ეტაპი 2: HTTPS მოთხოვნა

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

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

ეტაპი 3: საკონტროლო შეტყობინებები

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

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

ეტაპი 4: PPP იბარებს

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

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

ავთენტიფიკაციას რამდენიმე როლი აქვს

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

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

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

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

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