ერთი ზედმეტი ახალი ხაზი შეიძლება გააფუჭოს TLS CONNECT-ის შემდეგ

როდესაც CONNECT აბრუნებს 200-ს და TLS მაშინვე ვერ დეკოდირებს, შეამოწმეთ კონექტორის სასაზღვრო ბაიტები სერტიფიკატების ან შიფრების შეცვლამდე.

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

მინიმალური HTTP/1.1 CONNECT მოთხოვნა იყენებს CRLF-ს ხაზებს შორის და ცარიელ ხაზს ბოლოს:

b"CONNECT example.com:443 HTTP/1.1\r\nHost: example.com:443\r\n\r\n"

განათავსეთ ნებისმიერი ავტორიზაციის ველი ამ ბოლო ცარიელ ხაზამდე, ჩაშენებული ხაზის გადატეხის გარეშე. Python-ში "\n" ახალ ხაზს აღნიშნავს; უხეში სტრიქონი, რომელიც შეიცავს backslash-ს და ასო n-ს, არ აღნიშნავს. შეამოწმეთ, რომელ ბაიტებს აწარმოებს კოდირების დამხმარე, სანამ მათ წაშლას სცდით—ძველ დამხმარეებს შეეძლოთ ხაზების გადატეხის დამატება.

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

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

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