[squid-dev] [PATCH] Support tunneling of bumped non-HTTP traffic. Other SslBump fixes.

[Christos Tsantilas]

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 <christos at 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.
>