[squid-users] sslBump somehow interferes with authentication
Hi.
I have configured simple ssl peek/splice on squid 3.5.10 for some simple
cases, but in my production, where configs are complicated, it doesn't
work as expected - somehow it interferes with authentication.
Suppose we have a config like:
===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===
This is a part of an actually working config (with some local names
modification, just to read it easily). This config is straightforward:
- foo and bar are allowed without authentication
- then an explicit authentication occurs ('http_access deny
unauthorized' looks redundant, and yes, the config will be work without
it, but the thing is that this ACL 'unauthorized' is used to display a
specific deny_info page for the users who failed to authorize).
- it allows to browse some usually blocked sites at some amounts of time
called 'freetime'.
- this config is sslBump-ready, a 'blockssl' ACL exists, which matches
site names on SNI.
Now I'm adding sslBump:
===Cut===
acl step1 at_step SslBump1
ssl_bump peek step1
ssl_bump bump blockssl
ssl_bump splice all
===Cut===
As soon as I add sslBump, everything that is bumped, starts to be
blocking by 'http_access deny unauthorized' (everything that's spliced
works as intended). And I completely cannot understand why. Yes, I can
remove this line, but this way I'm loosing deny_info for specific cases
when someone fails to authorize, and plus - without sslBump it was
working, right ? Please help me understand this and solve the issue.
Thanks.
Eugene.
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] sslBump somehow interferes with authentication
On 12/11/2015 7:12 a.m., Eugene M. Zheganin wrote: > > As soon as I add sslBump, everything that is bumped, starts to be > blocking by 'http_access deny unauthorized' (everything that's spliced > works as intended). And I completely cannot understand why. Yes, I can > remove this line, but this way I'm loosing deny_info for specific cases > when someone fails to authorize, and plus - without sslBump it was > working, right ? Please help me understand this and solve the issue. > 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). Amos ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] sslBump somehow interferes with authentication
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. ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] sslBump somehow interferes with authentication
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@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
