WSS gjennom Squid er ikke det samme som en vanlig WebSocket-oppgradering
Skill krypterte WebSockets inne i CONNECT fra håndtering av vanlig HTTP Upgrade i en videresendende proxy.
Ser Squid en HTTP Upgrade-forespørsel, eller bare en tunnel som bærer kryptert trafikk? Det avgjør om HTTP Upgrade-kontrollene dens tar tak i feilen.
| Vanlig eksplisitt proxy-løp | Hva Squid møter |
|---|---|
wss:// | Vanligvis CONNECT, deretter destinasjons-TLS som bærer WebSocket-håndtrykket |
ws:// | En vanlig HTTP Upgrade-forespørsel som proxyen kan behandle |
Squids oppgraderingskontroll gjelder forespørsler den behandler. Den avdekker ikke krypterte HTTP-hoder inne i en vanlig ugjennomsiktig WSS-tunnel. TLS-avlytting eller annen spesiell proxybehandling endrer synligheten og kan føre med seg egne kompatibilitetskrav.
For WSS, finn hvor sekvensen stopper: tilkobling til proxyen, akseptert CONNECT, verifisert TLS, deretter applikasjonens håndtrykk. En avvisning før TLS er en annen feil enn en avvist vanlig Upgrade-forespørsel.
Hvis en endring av oppgraderingspolicyen er nødvendig, bruk direktivet for den installerte Squid-versjonen og tillat den nødvendige atferden spesifikt. Å tillate alle oppgraderingsprotokoller utvider policyen utover den aktuelle applikasjonen.
En vellykket HTTPS-sideforespørsel etablerer bare en del av løpet. Langvarig WebSocket-trafikk kan fortsatt feile på applikasjonskrav, tilkoblingens levetid eller begrensninger hos mellomledd, selv for samme vertsnavn.