[squid-dev] on_unsupported_protocol doesn't work for bumped https connecttions

[Tarik Demirci]

Hi,

I'm moving this topic to squid-dev as suggested.


On Wed, Nov 18, 2015 at 5:55 PM, Alex Rousskov
<rousskov at measurement-factory.com> wrote:
> On 11/18/2015 12:53 AM, Tarik Demirci wrote:
>
>> I did more detailed tests for this case. Constructing a tcp-in-https
>> connection results with error ERR_PROTOCOL_UNKNOWN in spite of
>> "on_unsupported_protocol tunnel all" conf directive. Is this a Squid
>> bug? Doc for on_unsupported_protocol says it works for bumped tunnels
>> but I can't confirm this in any way.
>>
>> I debugged the code and it fails in a check in clientTunnelOnError
>> function. By the time Squid understands it's not http inside https,
>> conn->nrequests value is 2. So conn->nrequests <= 1 check fails.
>
>
> This is a development topic. Consider moving this thread to squid-dev.
>
> AFAICT, the intended goal of the nrequests check is to prevent switching
> to tunnel mode after the tunnel has already been proven to carry a
> "supported" protocol (i.e., HTTPS or HTTP).
>
> I do not think that nrequests check is correct: The nrequests member is
> incremented on every request, so it may be very large if a browser
> switches to a tunnel after sending many regular requests:
>
>   GET
>   GET
>   GET
>   CONNECT
>

In my situation it's something like this because of ssl bump:

CONNECT
GET (or unknown protocol)

> I also suspect the check is difficult to get right because fake CONNECTs
> on intercepted connections and real CONNECTs on forwarded connections
> might be counted differently. I did not verify that, but it may explain
> why you are hitting this bug -- the code may have been tested with
> intercepted connections only and just "assumed" to work for CONNECT
> tunnels as well.

Does connect TUNNEL mean explicit proxy by client (client is proxy
aware)? If yes, this is not my case. I test this situation for
intercepted connections on 443 (using iptables REDIRECT).

>
> I recommend replacing nrequests check with a check based on a new
> tooLateToTunnel boolean data member. That member can be initialized to
> false and set to true after receiving valid HTTP request headers inside
> an inspected connection (at least).
>

I implemented your suggestion but failed. During ssl bump,
httpsSslBumpAccessCheckDone fires a fakeAConnectRequest. This CONNECT
request has an 'Host:' header. Therefore it makes tooLateToTunnel
value true which causes bypass to fail again.

>
> Thank you,
>
> Alex.
>

Thank you,

>
>> Here how I did the test:
>> - Install stunnel to both 'Netcat Server' and 'Client'.
>> - Add Issuer CA of the stunnel certificate to trusted authorities of
>> 'Squid Box'.
>> - Open a tcp connection with netcat through stunnel.
>>
>> This results with familiar ERR_PROTOCOL_UNKNOWN.
>>
>> Note: I'm confident that https setup is correct because redirecting
>> traffic to nginx instead of netcat results with a successfull
>> connection.
>>
>> Thanks,
>>
>>
>
-- 
Tarık Demirci