Ang WSS sa pamamagitan ng Squid ay hindi katulad ng simpleng WebSocket upgrade
Ihiwalay ang mga naka-encrypt na WebSocket sa loob ng CONNECT mula sa paghawak ng simpleng HTTP Upgrade sa isang forward proxy.
Nakikita ba ng Squid ang isang kahilingang HTTP Upgrade, o isang tunnel lamang na may dalang naka-encrypt na trapiko? Iyan ang nagtatakda kung tinutugunan ng mga kontrol nitong HTTP Upgrade ang pagkasira.
| Karaniwang landas ng hayagang proxy | Ano ang nakakaharap ng Squid |
|---|---|
wss:// | Karaniwang CONNECT, sinusundan ng TLS ng destinasyon na may dalang handshake ng WebSocket |
ws:// | Isang simpleng kahilingang HTTP Upgrade na kayang iproseso ng proxy |
Ang kontrol sa pag-upgrade ng Squid ay tungkol sa mga kahilingang ipinoproseso nito. Hindi nito inilalantad ang naka-encrypt na mga header ng HTTP sa loob ng karaniwang malabong tunnel ng WSS. Binabago ng interception ng TLS o iba pang espesyal na paghawak ng proxy ang visibility at maaaring magdala ng sarili nitong mga pangangailangan sa pagiging compatible.
Para sa WSS, hanapin kung saan humihinto ang pagkakasunod-sunod: koneksyon sa proxy, tinanggap na CONNECT, na-verify na TLS, pagkatapos ang handshake ng aplikasyon. Ang pagtanggi bago ang TLS ay ibang pagkabigo kaysa sa tinanggihang simpleng kahilingang Upgrade.
Kung kailangan ng pagbabago sa patakaran sa pag-upgrade, gamitin ang direktiba para sa naka-install na bersyon ng Squid at partikular na payagan ang kinakailangang pag-uugali. Ang pagpayag sa lahat ng protocol ng pag-upgrade ay nagpapalawak ng patakaran lampas sa partikular na aplikasyon.
Ang matagumpay na kahilingan sa pahinang HTTPS ay nagtatatag lamang ng bahagi ng landas. Ang pangmatagalang trapiko ng WebSocket ay maaari pa ring mabigo dahil sa mga pangangailangan ng aplikasyon, tagal ng koneksyon o mga paghihigpit ng tagapamagitan, kahit para sa parehong hostname.