[squid-users] sslBump somehow interferes with authentication

[Eugene M. Zheganin]

Hi.

On 11.11.2015 23:44, Amos Jeffries wrote:
> Proxy-authentication cannot be performed on MITM'd traffic. That
> includes SSL-bump decrypted messages.
>
> However, unlike the other methods SSL-bump CONNECT wrapper messages in
> explicit-proxy traffic can be authenticated and their credentials
> inherited by the messages decrypted. Squid should be doing that. But
> again cannot do it for the fake/synthetic ones it generates itself on
> intercepted port 443 traffic.
>
> So the question becomes, why are foo and bar ACLs not matching?
>  http_access rules are applied separately to the CONNECT wrapper message
> and to the decrypted non-CONNECT HTTP message(s).
>
>
Yeah, completely my fault - I forgot to tell what URL user is trying to
browse and what matches when.
Once again.

===Cut===
acl freetime time MTWHF 18:00-24:00

acl foo dst 192.168.0.0/16
acl bar dstdomain .bar.tld

acl users proxy_auth steve
acl users proxy_auth mike
acl users proxy_auth bob

acl unauthorized proxy_auth stringthatwillnevermatch

acl block dstdomain "block.acl"
acl blockssl ssl::server_name "block.acl"

http_access allow foo
http_access allow bar

http_access deny unauthorized

http_access allow blockssl users freetime
http_access allow block users freetime
http_access deny blockssl users
http_access deny block users
http_access allow users
http_access deny all
===Cut===

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.

Thanks.
Eugene.