[squid-users] sslBump somehow interferes with authentication

Eugene M. Zheganin emz at norma.perm.ru
Wed Nov 11 19:20:06 UTC 2015


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.


More information about the squid-users mailing list