On 08/27/2015 04:50 AM, john jacob wrote: > with the proxy connections I am encountering some > peculiar behavior with scenario 3 (ie when a non bumped https CONNECT is > denied by eCAP). Instead of terminating the connection, it is logged as > TAG_NONE/200 in the access log and getting bumped (a dynamic certificate > is generated) and then getting terminated. The behavior disappears and > works if I comment the "peek all" line. > > I am not sure if this is a bug or an expected behavior. Most of the stuff you are describing matches my expectations, but there is not enough information in a couple of cases: * "getting bumped and then getting terminated". Terminated without serving an error page to the bumped client? Is there a request after CONNECT? Is the client happy about the bumped connection? How many CONNECT requests does your eCAP adapter see (and deny) in this case? * "works if I comment the 'peek all' line". Works how? I would expect Squid to bump and then serve an error page to the user on a bumped connection. How many CONNECT requests does your eCAP adapter see (and deny) in this case? Here is some background so that you can debug this further: Denying a CONNECT request implies serving an error page to the user. However, the user will not see the error page if Squid sends it as a response to the CONNECT request (due to lazy browsers security policies; nothing to do with Squid). The only way to show that error page to the user is to bump the client connection and then serve the error page over that bumped connection in response to the first bumped request. If your eCAP adapter denies CONNECT during an SslBump step, Squid should bump the client connection (200 OK) and serve an error page to the user in response to the first request on that bumped connection, if any (TAG_NONE/403?). You can find more information about this behaviour at http://bazaar.launchpad.net/~squid/squid/trunk/revision/13759 but some of that old info is probably out of date by now. > Of course the proxy bumped connection works fine if I selectively peek > for intercepted connections (ssl_bump peek <if only in intercepted > mode>), but in this case I am getting duplicate entries in the access > log file (ie 2 CONNECT log messages for each https CONNECT) for > intercepted mode https connections. This is expected if you peek at step1. The second CONNECT should have SNI information (but it often does not -- it is complicated and there are bugs/missing features in that area of the code). If you do not need SNI, you can make all decisions during the first CONNECT. > The same goes for other ACL > combinations like the below resulting in duplicated log messages > > ssl_bump server-first <ip of the domain to be bumped> > ssl_bump splice <only if the request hit the proxy ip:port and not the > intercept/transparent ip :port> > ssl_bump peek all > ssl_bump splice all In general, it is a bad idea to combine legacy (server-first) and modern (peek/stare/splice/bump/terminate) rules. If at all possible, use modern rules. Alex. _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
