[squid-users] Squid Websocket Issue

[Amos Jeffries]

On 2017-01-03 05:49, Hardik Dangar wrote:
> Hey Eliezer,
> 
> The issue was with whatsapp web socket was not working, here is
> detailed information about issue
> ------------
> 
> Here is some information about my squid version,
> 
> Squid Cache: Version 3.5.22-20161115-r14113
> Service Name: squid
> configure options:  '--prefix=/usr' '--localstatedir=/var/squid'
> '--libexecdir=/lib/squid' '--srcdir=.' '--datadir=/share/squid'
> '--sysconfdir=/etc/squid' '--with-default-user=proxy'
> '--with-logdir=/var/log/squid' '--with-pidfile=/var/run/squid.pid'
> '--with-openssl' '--enable-ssl-crtd' '--enable-inline'
> '--disable-arch-native' '--enable-async-io=8'
> '--enable-storeio=ufs,aufs,diskd,rock'
> '--enable-removal-policies=lru,heap' '--enable-delay-pools'
> '--enable-follow-x-forwarded-for' '--enable-url-rewrite-helpers=fake'
> '--enable-ecap'
> 
> My squid config file is located at, http://pastebin.com/raw/LvDxEF4x
> 
> Now the issue is whenever someone requests a page which contains web
> socket requests response is always bad request.
> Here is an example,
> 
> Request URL:wss://w4.web.whatsapp.com/ws [1]
> Request Method:GET
> Status Code:400 Bad Request
> 
> Response Headers
> #################
> Connection:keep-alive
> Date:Sat, 17 Dec 2016 09:05:36 GMT
> Transfer-Encoding:chunked
> X-Cache:MISS from Proxy
> 
> Request Headers
> #################
> Accept-Encoding:gzip, deflate, sdch, br
> Accept-Language:en-US,en;q=0.8
> Cache-Control:no-cache
> Connection:Upgrade
> Host:w4.web.whatsapp.com [2]
> Origin:https://web.whatsapp.com
> Pragma:no-cache
> Sec-WebSocket-Extensions:permessage-deflate; client_max_window_bits
> Sec-WebSocket-Key:kzrB2ZcMHDAqvjDNXnjL/w==
> Sec-WebSocket-Version:13
> Upgrade:websocket
> User-Agent:Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML,
> like Gecko) Chrome/55.0.2883.75 Safari/537.36
> 
> My question is how we can work with web socket requests in squid or if
> not by pass them squid. My squid instance is in interception mode and
> requests are intercepted at instance via iptables and forwarded to
> squid using below rules,

WebSockets has several ways to initiate connections:

1) native WebSocket port
  - requires any intermediary has native Websocket support

2) CONNECT tunnel (maybe with Upgrade)
  - requires only that the intermediary has HTTP CONNECT support

3) GET request with Upgrade
  - requires that the intermediary has both HTTP Upgrade and WebSockets 
native support


Squid supports method #2.

The transaction you are showing as broken is mechanism #3. Both the 
Upgrade and WebSockets support requirements are not existing in Squid.

That particular request going through a non-WebSockets proxy is supposed 
to be passed to the server as a regular GET request (without Upgrade). 
Exactly what Squid does. The server itself is producing the 400 response 
instead of using alternative things like HTTP long-polling in place of 
WebSockets. That is its choice, nothing to do with Squid and a perfectly 
valid choice on the servers part.

If WhatsApp tried the supported #2 mechanism it would work through 
Squid.


> 
> ----------------------------------------------------------
> 
> SOLUTION TO ABOVE PROBLEM WAS,
> 

... to splice instead of bump.

> 
> So basically websockets are connected as normal https request( i think
> this is a very nature of Web sockets and define somewhere in web
> socket standards).

No, that is the nature of HTTPS when not being bump'ed. Squid is not 
involved in the encrypted request when splicing. So it does not matter 
if it really is HTTPS or actually encrypted WebSockets.

The HTTPS goes through Squid as a CONNECT tunnel. Which for WebSockets 
is connection method #2 above - which is supported and works.


I think your problem is that you are expecting unrealistic things from 
decrypted HTTPS. *HTTPS* being the critical word there. Bumping decrypts 
HTTPS, it does not decrypt other protocols - including WebSockets.

Since the WhatsApp traffic is/was intercepted the client software has no 
knowledge of the proxy existing so it is not realistic to expect it to 
attempt the CONNECT method, even as a failover.

Amos