On 10/16/2018 06:29 AM, Amish wrote: > It seems that current algorithm for ssl-bump is: > > 1) Browser sends CONNECT request > 2) Squid sends status 200 Connection Established > 3) Check ACL > 4) If denied, bump the connection with squid certificate > 5) If allowed, go ahead with tunneling / bumping as applicable Kind of. The actual sequence in this particular case is a bit different because Squid discovers a denied CONNECT _before_ Squid decides how to respond to that CONNECT request: 1) Receive CONNECT request. 3) Check access controls. The request is denied! 2) Send HTTP 200 Connection Established (see below for "why"). 4) Bump the connections to deny/redirect the first bumped request. > In my opinion correct flow should be like this: > > 1) Browser sends CONNECT request > 2) Check ACL > 3) If denied, return with 307 (or 302) > 4) If allowed, go ahead with tunneling / bumping as applicable Unfortunately, that ideal sequence does not work well in practice because popular browsers ignore CONNECT responses other than HTTP 200 and 407. As a consequence, if you want to redirect "secure" browser traffic, Squid has to bump it first. HTH, Alex. _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
