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

[Amos Jeffries]

On 18/10/2016 7:54 a.m., Christos Tsantilas wrote:
> On 10/17/2016 05:42 PM, Alex Rousskov wrote:
>> On 10/17/2016 01:57 AM, Christos Tsantilas wrote:
>>> On 10/14/2016 02:30 PM, Marcus Kool wrote:
>>>> Squid sends the following line to the URL rewriter:
>>>> (unknown)://173.194.76.188:443 <IP>/<IP> - NONE
>>
>>> 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".
>>
>> How about sending a CONNECT-like "173.194.76.188:443" URI instead of a
>> malformed one? That is, using option #3 below:
>>
>> 1. Current syntactically malformed URI: (unknown)://host:port"
>>
>> 2. Lying about the protocol/scheme: http://host:port/
>>
>> 3. Authority form URI, as in HTTP CONNECT: host:port
>>
>> 4. Using made-up URI scheme: tcp://host:port/
>>    See http://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml
> 
> 
> We can use on of the 3 or 4. We can just define a new proto for this
> case eg a PROTO_TCP or PROTO_TUNNEL and define a Uri::Scheme for this.
> 
> Personally I like the tcp://host:port. But I do not have actually a
> strong opinion. Looks that we should also take in account squid helpers
> (and maybe other external tools like log analysers).
> 
> Opinions?


If TLS and provides ALPN stating unsupported protocol, use that as the
UriScheme image with PROTOCOL_OTHER,

else if Tunnel-Protocol from clients CONNECT, same using that value ...,

Otherwise the CONNECT with authority-URI Alex mentioned is correct for
both helpers and logs.

Basically, the most accurate true information - no lies or guesses.

If a helper assumes that port 443 means HTTPS that is a helper bug,
nothing we can do about it (unless its our helper).

Create a new LogTag flag for unsupported protocol and always set it for
these transactions, regardless of what URI is able to be used.

Amos