WSS via Squid is niet hetzelfde als een gewone WebSocket-upgrade
Scheid versleutelde WebSockets binnen CONNECT van de afhandeling van gewone HTTP Upgrade in een forward-proxy.
Ziet Squid een HTTP Upgrade-verzoek, of alleen een tunnel met versleuteld verkeer? Dat bepaalt of de HTTP Upgrade-besturing het probleem aanpakt.
| Gewoon pad via expliciete proxy | Wat Squid tegenkomt |
|---|---|
wss:// | Meestal CONNECT, gevolgd door TLS van de bestemming dat de WebSocket-handshake draagt |
ws:// | Een gewoon HTTP Upgrade-verzoek dat de proxy kan verwerken |
De upgrade-besturing van Squid betreft verzoeken die het verwerkt. Het legt versleutelde HTTP-headers in een gewone ondoorzichtige WSS-tunnel niet bloot. TLS-onderschepping of andere speciale proxyafhandeling verandert de zichtbaarheid en kan eigen compatibiliteitseisen met zich meebrengen.
Zoek bij WSS waar de reeks stopt: verbinding met de proxy, geaccepteerde CONNECT, geverifieerde TLS, dan de handshake van de toepassing. Een weigering vóór TLS is een ander falen dan een geweigerd gewoon Upgrade-verzoek.
Als een wijziging van het upgradebeleid nodig is, gebruik dan de richtlijn voor de geïnstalleerde Squid-versie en sta het vereiste gedrag specifiek toe. Alle upgradeprotocollen toestaan verbreedt het beleid voorbij de specifieke toepassing.
Een geslaagd HTTPS-paginaverzoek legt slechts een deel van het pad vast. Langdurig WebSocket-verkeer kan alsnog mislukken door toepassingseisen, levensduur van de verbinding of beperkingen van tussenliggende partijen, zelfs voor dezelfde hostnaam.