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

[Alex Rousskov]

On 10/17/2016 10:56 PM, Amos Jeffries wrote:
> 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.

I agree in principle, but recommend doing just #3 for now, in this
patch: Everything else mentioned by Amos sounds good, and we can
probably add more scheme/protocol information sources as well, but
accurate extraction and reporting of unsupported protocol schemes is a
separate (and clearly non-trivial!) issue.

Let's fix the much bigger known problems first, which is what the
proposed patch attempts to do. I hope that option #3 allows us to do
that without causing a regression that Marcus have identified and
without creating extra work compared to the final state where more
schemes may be reported as outlined by Amos (and option #4).


Thank you,

Alex.