[squid-users] websockets through Squid

[Alex Rousskov]

On 10/15/20 10:08 AM, Vieri wrote:
>  On Tuesday, October 13, 2020, 6:14:18 PM GMT+2, Alex Rousskov wrote: 
>> You should probably follow up with Gentoo folks responsible for this Squid customization.

> Squid 5 now builds and installs perfectly on Gentoo Linux with a few
> custom changes to the distro's package installation script. I hope
> the devs will include these changes so Squid 5 can be readily
> available to everyone.

Thank you for reporting your fixes to Gentoo.


> I added this to Squid 5:

> http_upgrade_request_protocols OTHER allow all

> Am I right if I state that this should allow any protocol not just WebSockets?

Yes.

> In other words, I do not need to be specific with
> 'http_upgrade_request_protocols WebSocket allow all' unless I want
> to, right?

Just in case somebody else starts copy-pasting the above rule into their
configurations: The standard (RFC 6455) WebSocket protocol name in HTTP
Upgrade requests is "websocket". Squid uses case-sensitive comparison
for those names so you should use "websocket" in squid.conf.

Other than that correction, you are right -- a bare OTHER rule is more
risky in general but is sufficient for allowing WebSocket upgrades.


> Unfortunately, after reloading Squid 5 the client browser still states the same:
> 
> The connection to wss://ed1lncb65702.webex.com/direct?type=websocket&dtype=binary&rand=1602769907574&uuidtag=9E73C14G-1580-43B4-B8D4-91453FCF1939&gatewayip=MY_IP_ADDR was interrupted while the page was loading.
> 
> And in access.log I can see this:
> 
> [Thu Oct 15 15:52:27 2020].411  29846 10.215.144.48 TCP_TUNNEL/101 0 GET https://ed1lncb65702.webex.com/direct? - ORIGINAL_DST/62.109.225.174 -
> [Thu Oct 15 15:52:27 2020].831    125 10.215.144.48 NONE_NONE/000 0 CONNECT 62.109.225.174:443 - ORIGINAL_DST/62.109.225.174 -
> [Thu Oct 15 15:52:28 2020].786     11 10.215.111.210 NONE_NONE_ABORTED/000 0 CONNECT 44.233.111.149:443 - HIER_NONE/- -
> [Thu Oct 15 15:52:37 2020].414  29870 10.215.144.48 TCP_TUNNEL/101 0 GET https://ed1lncb65702.webex.com/direct? - ORIGINAL_DST/62.109.225.174 -
> [Thu Oct 15 15:52:37 2020].919    107 10.215.144.48 NONE_NONE/000 0 CONNECT 62.109.225.174:443 - ORIGINAL_DST/62.109.225.174 -

> What does NONE_NONE/000 mean?

It is a (relatively minor) bug in Squid. Squid probably forgot to set
the exact outcome of the transaction at transaction logging time and
probably logged absent status code as 000. We already have a project
that should fix the status code handling in such cases.

The important part here is the existence of those extra transactions.
They may be related to SslBump if you are bumbing this traffic, but then
I would expect a slightly different access.log composition.


> Where can I go from here?
> What can I try to debug this further?

The log shows successful tunnel negotiation (two TCP_TUNNEL/101 entries)
and potentially problematic transactions. It is not clear (to me)
whether they all correspond to the same client interaction. It is
possible that the client successfully tunneled some websocket
transactions but failed to tunnel others. It is also possible, although
less likely, that the client has detected a proxy presence and refused
to tunnel despite receiving a successful 101 response from Squid.

IMO, further triage requires analyzing debugging cache.log. In my
experience, such analysis usually requires developer expertise. You can
try posting a link to compressed cache.log containing just the
corresponding transactions/interactions with debug_options set to
"ALL,9" (this may log passwords, keys, and such so be careful). Somebody
here may volunteer to analyze your log for you.

https://wiki.squid-cache.org/SquidFaq/BugReporting#Debugging_a_single_transaction


HTH,

Alex.