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)://173.194.76.188:443 <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)://173.194.76.188:443".
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.
Regards,
Christos
Marcus
Quoting Christos Tsantilas <[email protected]>:
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
[email protected]
http://lists.squid-cache.org/listinfo/squid-dev
