WSS via Squid n'est pas la même chose qu'une simple mise à niveau WebSocket
Distinguez les WebSocket chiffrés dans CONNECT du traitement d'un HTTP Upgrade en clair dans un proxy direct.
Squid voit-il une requête HTTP Upgrade, ou seulement un tunnel transportant du trafic chiffré ? Cela détermine si ses contrôles HTTP Upgrade traitent la panne.
| Chemin ordinaire par proxy explicite | Ce que Squid rencontre |
|---|---|
wss:// | Généralement CONNECT, suivi du TLS de destination portant la poignée de main WebSocket |
ws:// | Une requête HTTP Upgrade en clair que le proxy peut traiter |
Le contrôle des mises à niveau de Squid concerne les requêtes qu'il traite. Il ne révèle pas les en-têtes HTTP chiffrés à l'intérieur d'un tunnel WSS opaque ordinaire. L'interception TLS ou un autre traitement spécial du proxy modifie la visibilité et peut imposer ses propres exigences de compatibilité.
Pour WSS, trouvez où la séquence s'arrête : connexion au proxy, CONNECT accepté, TLS vérifié, puis la poignée de main de l'application. Un refus avant TLS est une panne différente d'une requête Upgrade en clair refusée.
Si un changement de politique de mise à niveau est nécessaire, utilisez la directive de la version de Squid installée et autorisez précisément le comportement requis. Autoriser tous les protocoles de mise à niveau élargit la politique au-delà de l'application concernée.
Une requête de page HTTPS réussie n'établit qu'une partie du chemin. Le trafic WebSocket de longue durée peut encore échouer sur les exigences de l'application, la durée de vie de la connexion ou les restrictions d'un intermédiaire, même pour le même nom d'hôte.