On 10/14/2016 02:30 PM, Marcus Kool wrote:
I started testing this patch and observed one unwanted side effect of
this patch:
When a client connects to mtalk.google.com,
Squid sends the following line to the URL rewriter:
(unknown):// <IP>/<IP> - NONE

Thank you.
I should have refer on this effect.

Squid has already established a bumbed TLS tunnel between client and server.

The client sends a request which is not an HTTP request and squid because of "on_unsupported_protocol" decides to just tunnel any new bytes from client to the server and vice versa.

Squid generates internally request to serve the non-HTTP client request, and this is what you are seeing as "(unknown)://".

This is an effect of this patch. Personally I found it a good idea, it is not a bad way to express a non supported protocol.
But I would like to hear proposals for better handling these cases.



Quoting Christos Tsantilas <chris...@chtsanti.net>:

Use case: Skype groups appear to use TLS-encrypted MSNP protocol
instead of HTTPS. This change allows Squid admins using SslBump to
tunnel Skype groups and similar non-HTTP traffic bytes via
"on_unsupported_protocol tunnel all". Previously, the combination
resulted in encrypted HTTP 400 (Bad Request) messages sent to the
client (that does not speak HTTP).

Also this patch:
 * fixes bug 4529: !EBIT_TEST(entry->flags, ENTRY_FWD_HDR_WAIT)
assertion in FwdState.cc.

 * when splicing transparent connections during SslBump step1, avoid
access-logging an extra record and log %ssl::bump_mode as the expected
"splice" not "none".

 * handles an XXX comment inside clientTunnelOnError for possible
memory leak of client streams related objects

 * fixes TunnelStateData logging in the case of splicing after peek.

This is a Measurement Factory project.

squid-dev mailing list

Reply via email to