WSS Squid-ის გავლით არ არის იგივე, რაც ჩვეულებრივი WebSocket განახლება
გამოყავით CONNECT-ის შიგნით დაშიფრული WebSocket-ები წინა პროქსიში ჩვეულებრივი HTTP Upgrade-ის დამუშავებისგან.
ხედავს Squid HTTP Upgrade მოთხოვნას, თუ მხოლოდ დაშიფრულ ტრაფიკის მატარებელ გვირაბს? ეს განსაზღვრავს, აგვარებს თუ არა მისი HTTP Upgrade კონტროლი ხარვეზს.
| ჩვეულებრივი ღია პროქსის გზა | რასაც Squid ხვდება |
|---|---|
wss:// | ჩვეულებრივ CONNECT, შემდეგ დანიშნულების TLS, რომელიც WebSocket-ის ხელის ჩამორთმევას ატარებს |
ws:// | ჩვეულებრივი HTTP Upgrade მოთხოვნა, რომლის დამუშავებაც პროქსის შეუძლია |
Squid-ის განახლების კონტროლი ეხება მოთხოვნებს, რომლებსაც თავად ამუშავებს. ის არ ამხელს დაშიფრულ HTTP სათაურებს ჩვეულებრივი გაუმჭვირვალე WSS გვირაბის შიგნით. TLS-ის ჩარევა ან პროქსის სხვა განსაკუთრებული დამუშავება ცვლის ხილვადობას და შეიძლება თავისი თავსებადობის მოთხოვნები მოიტანოს.
WSS-ისთვის იპოვეთ, სად ჩერდება თანმიმდევრობა: კავშირი პროქსისთან, მიღებული CONNECT, შემოწმებული TLS, შემდეგ აპლიკაციის ხელის ჩამორთმევა. უარი TLS-ამდე სხვა ხარვეზია, ვიდრე უარყოფილი ჩვეულებრივი Upgrade მოთხოვნა.
თუ განახლების პოლიტიკის ცვლილება საჭიროა, გამოიყენეთ დაყენებული Squid-ის ვერსიის დირექტივა და კონკრეტულად დაუშვით საჭირო ქცევა. ყველა განახლების პროტოკოლის დაშვება პოლიტიკას კონკრეტულ აპლიკაციაზე მიღმა აფართოებს.
წარმატებული HTTPS გვერდის მოთხოვნა გზის მხოლოდ ნაწილს ამყარებს. ხანგრძლივი WebSocket ტრაფიკი მაინც შეიძლება ჩავარდეს აპლიკაციის მოთხოვნების, კავშირის სიცოცხლის ან შუამავლების შეზღუდვების გამო, იმავე ჰოსტის სახელისთვისაც კი.