[squid-dev] [RFC] "Splicing" bumped requests to resolve\workaround WebSockets issues.

[Amos Jeffries]

On 18/07/2016 8:34 a.m., Eliezer Croitoru wrote:
> Alex thanks for clearing things out.
> I remember something's vaguely and this is why I didn't quote anything.
> I tried searching for something in the squid-dev list or irc but I couldn't
> found it.
> 
> "tunnel after bump" is indeed the right term and despite to what some think
> in many cases the issue is not certificate pinning but...
> A specially crafted binary protocol that cannot be intercepted by an HTTP
> proxy.
> 
> About the on_unsupported_protocol , I am assuming it's part of the:
> http://wiki.squid-cache.org/Squid-4?highlight=%28on_unsupported_protocol%29
> 
> The test cases I can think about are couple:
> - CONNECT of a pinned certificate based connection(MS, SKYPE)
> - CONNECT of a non TLS based connection(SKYPE)
> - CONNECT of a http websocket connection(WHATSAPP?)
> - CONNECT of a HTTPS based connection, non websocket(a simple banking site)
> - CONNECT of a HTTPS based websocket connection(the CentOS\Fedora cockpit
> have these, other suggections are welcome)
> - intercepted connection for each of the cases above
> 
> I think that when we could test each and every one of these
> cases(successfully) then we can move forward from beta to the next release.
> (only for the bump, splice, tunnel, on_unsupported_protocol aspect of squid)


Well, that would be nice to have. But is not one of the things holding
Squid-4 in beta. The on_unsupported_protocol feature already meets its
original design behaviour (detecting and handling *non-TLS* protocols on
port 443) well enough for release as experimental feature in a stable
Squid release cycle.

We are currently on Stage 3 of the release process and waiting to
achieve the major-bugs criteria listed for reaching Stage 4:
<http://wiki.squid-cache.org/ReleaseProcess#General_Release_Process_Guidelines>

This time around I'm experimenting with not doing stage-2 (branching)
until Stage-4 is reached.

Amos