WSS tramite Squid non è la stessa cosa di un semplice upgrade WebSocket
Separare i WebSocket crittografati dentro CONNECT dalla gestione di un HTTP Upgrade in chiaro in un proxy forward.
Squid vede una richiesta HTTP Upgrade o solo un tunnel che trasporta traffico crittografato? Questo determina se i suoi controlli HTTP Upgrade affrontano il guasto.
| Percorso ordinario tramite proxy esplicito | Ciò che Squid incontra |
|---|---|
wss:// | Di solito CONNECT, seguito dal TLS di destinazione che trasporta l'handshake WebSocket |
ws:// | Una richiesta HTTP Upgrade in chiaro che il proxy può elaborare |
Il controllo degli upgrade di Squid riguarda le richieste che elabora. Non rivela le intestazioni HTTP crittografate all'interno di un normale tunnel WSS opaco. L'intercettazione TLS o un'altra gestione speciale del proxy cambia la visibilità e può introdurre propri requisiti di compatibilità.
Per WSS, individuare dove si ferma la sequenza: connessione al proxy, CONNECT accettato, TLS verificato, poi l'handshake dell'applicazione. Un rifiuto prima del TLS è un guasto diverso da una richiesta Upgrade in chiaro negata.
Se serve un cambiamento della politica di upgrade, usare la direttiva per la versione di Squid installata e consentire specificamente il comportamento necessario. Consentire tutti i protocolli di upgrade amplia la politica oltre l'applicazione specifica.
Una richiesta di pagina HTTPS riuscita stabilisce solo una parte del percorso. Il traffico WebSocket di lunga durata può comunque fallire per requisiti dell'applicazione, durata della connessione o restrizioni degli intermediari, anche per lo stesso nome host.