WRONG_VERSION_NUMBER პროქსისთან: შეამოწმეთ HTTP და HTTPS

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

დანიშნულება https://example.com/-ის მსგავსად და პროქსი http://proxy.example:8080-ის მსგავსად ჩვეულებრივი წყვილია. მეორე URL-ის HTTPS-ად შეცვლა კლიენტს ეუბნება, რომ თავისი საუბარი თავად პროქსისთან დაშიფროს. ეს არ არის HTTPS საიტების დაშვების მითითება.

იპოვეთ პირველი TLS საუბარი

HTTP პროქსის შემთხვევაში კლიენტს შეუძლია ჯერ CONNECT გაგზავნოს და HTTP პასუხი მიიღოს. მხოლოდ ამის შემდეგ იწყებს დანიშნულების TLS-ს გვირაბის შიგნით. HTTPS პროქსის შემთხვევაში ჯერ მოდის ცალკე TLS კავშირი პროქსისთან.

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

1. ჩაიწერეთ პროქსის URL სქემის ჩათვლით და საბოლოო წერტილის დოკუმენტირებული პროტოკოლი.
2. გაარკვიეთ, მოხდა თუ არა ჩავარდნა CONNECT პასუხამდე, დანიშნულების TLS-ის დროს, თუ თავად პროქსის სერტიფიკატის შემოწმებისას.
3. ძველი გვერდულების შედარებისას შეამოწმეთ კლიენტისა და დამოკიდებულებების ფაქტობრივი ვერსიები. ადრინდელი პროქსის იმპლემენტაციები ზოგჯერ სქემას სხვაგვარად განიხილავდნენ.

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

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