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

[Christos Tsantilas]

I am attaching a new patch.
This is defines a new proto the PROTO_TCP, and for this prints the url 
in the form host:port.

There are no other changes from t8 patch.

On 10/18/2016 08:52 AM, Alex Rousskov wrote:
> 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.
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SQUID-211-Skype_groups_and_msnp_bypass-t9.patch
Type: text/x-patch
Size: 98524 bytes
Desc: not available
URL: <http://lists.squid-cache.org/pipermail/squid-dev/attachments/20161019/2378de7d/attachment-0001.bin>