Hi, I'm moving this topic to squid-dev as suggested.
On Wed, Nov 18, 2015 at 5:55 PM, Alex Rousskov <[email protected]> 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 _______________________________________________ squid-dev mailing list [email protected] http://lists.squid-cache.org/listinfo/squid-dev
