On 10/05/18 12:31, OlegH1 wrote: > Hi, > > I'm seeing some users of mine use squid proxy and cannot connect via > WebSocket because the Upgrade and Connection headers are striped. All > connections are over wss:// (TLS). > > My question is how possible that squid decrypts the packet, omit those > headers and encrypt. I saw there is a "SSL bump" extension that allows it (I > guess the "fake" cert should be install in the computers explicitly) - but > even if it's possible, why those headers are stripped? Unless you configured Squid SSL-Bump features to be enabled Squid does not decrypt anything. So it will only be dealing with the HTTP side of the traffic. WebSockets is a sub-protocol that operates over HTTP as well as HTTPS. So the headers are can be available to Squid in un-encrypted traffic - that is a client software choice. If HTTP is used Squid lack of support for HTTP/1.1 Upgrade is in effect. A client that properly follows the WebSocket protocol should have several fallback connection types it can use instead of HTTP through the proxy. Those choices include native WebSockets protocol on a non-HTTP(S) port, or continuing to use HTTP messaging (working) instead of WebSocket (not working). > > I saw several topics regard this issue, but didn't really understand the > problem. If someone set a squid proxy with SSL bump, how is it even possible > that squid blocks it? If SSL-Bump is configured, Squid decrypts the TLS layer. Exposing the fact that the supposedly "HTTPS" tunnel actually contains WebSocket protocol instead of HTTP(S). Since WebSocket and HTTP/1.1 Upgrade to start it is not supported by Squid one of two things happen; a) the HTTP/1.1 Upgrade header (if any) gets removed when the request is relayed to the server, or b) WebSocket native protocol has Squid on_unsupported_protocol action performed - if your Squid is one of the older version that lack that directive the connection just gets rejected. > I tried to use squid locally on my computer and it > looks that those headers passed just fine (connection initiated correctly), > so why is it mentioned that those headers are not supported? > They should not have been relayed. If properly working the Upgrade header should be listed in the Connection: header which causes it to be removed by Squid (or any other middleware without Upgrade:WebSocket support) on the purely HTTP(S) traffic sent to servers. I suspect you omitted that mandatory Connection:Upgrade header in your test. Amos _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users