Hi. On 12.11.2015 0:06, Eugene M. Zheganin wrote: > So, the user starts it's browser and opens the URL 'https://someurl'. > And this URL matches both 'block' and 'blockssl' ACLs, one I created for > you know... usual matching and one - for sslBump, since dstdomain ACLs > cannot work there. So, the main idea here is to actually show some > information to the user, when he's trying to visit some blocked site via > TLS and that site isn't allowed - because all the user sees in such > situation are various browser-depending error pages, like "Proxy server > refusing connections" (Firefox) or some other brief error (cannot > remember it exactly) in Chrome - so user thinks it's technical error > and starts bothering tech support. Can this goal be achieved for a > configuration with user authentication ? ACL 'foo' and ACL 'bar' don't > match 'somesite' because they are created to match some traffic that is > allowed to all proxy users, regardless of their authentication, and I > listed these ACLs here to give proper representation of my ACL structure > - there's a part without authentication, and there's a part with. > Follow-up: the traffic isn't intercepted proxy traffic, it's a traffic between a browser and a proxy, configured in that browser. If I remove the line http_access deny unauthorized I'm receiving an sslBumped traffic from the sites that match the 'blockssl' ACL, and this traffic goes through the authentication chain. The question is - why this line above makes the whole scheme to fall apart. Thanks. Eugene. _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
