[squid-dev] on_unsupported_protocol doesn't work for bumped https connecttions
tarik at tarikdemirci.com
Fri Nov 20 13:55:49 UTC 2015
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:
In my situation it's something like this because of ssl bump:
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,
>> 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
More information about the squid-dev