[squid-users] High CPU Usage with ssl_bump

[Odhiambo Washington]

On 22 April 2016 at 02:16, Alex Rousskov <rousskov at measurement-factory.com>
wrote:

> On 04/21/2016 03:26 PM, Odhiambo Washington wrote:
> > On 21 April 2016 at 23:14, Alex Rousskov wrote:
> >     Logging aside, your latest random configuration is equivalent to
> >     [...] not intercepting SSL at all, which brings
> >     us back to the old question: What do you want Squid to do?
>
>
> > If I could intercept SSL and do nothing EXCEPT subject the domains to
> > time ACLs, that'd be all.
>
> You are going back to the problem we have already discussed. Please slow
> down and translate your description above into what should happen to
> user connections that match your "time ACLs".
>


*slow down mode engaged*

You have given me these two templates:

(1)
If you want Squid to not intrude except when terminating prohibited traffic,
then start with this sketch:

  ssl_bump terminate prohibited_traffic
  ssl_bump peek all
  ssl_bump splice all

I would have preffered this option, first because it doesn't involve me
installing my CA on all user devices and secondly because of no intrusion.
However I cannot figure out how to deal with this when it comes to ACLs
because '*terminate*' isn't really what I think I want. What I want is as
follows:
(a) squid receives requiest from a particular host for facebook.com. Host
is identified by MAC Address or IP
(b) squid decides (based on ACLs) if host is allowed access to facebook.com
at this time, then allows it
(c) squid throws an error message if host is not allowed access at this
time.

If I could achieve the above, I will be fine. How to craft the configs is
my trouble. I keep fumbling.


(2)
If you want Squid to intrude (where possible) and block prohibited
traffic, then install your CA certificates on all user devices and start
with this sketch:

  ssl_bump splice things_that_are_impossible_to_bump
  ssl_bump stare all
  ssl_bump bump all
  http_access deny prohibited_traffic

Now here, the CA challenge abounds. We have a guest SSID on our WLAN and
this means I have to install the CAs even for guests or redo the network to
be able to accommodate guest users browsing without being subjected to our
internal policies.



>
> * Does "subject the domains to time ACLs" mean "immediately close
> connections that match" those ACLs?
>

No.


>
> * Or does it mean "serve Squid error pages" over connections that match
> those ACLs?
>

Yes.


>
> Once you decide, apply one of the two templates provided (the two
> templates correspond to which of the two questions you answer "yes").
>
>
> > I just want the data passing through squid for me to determine who is
> > allowed to access it and at what time.
>
> Assume Squid has made that access determination you want to make, and
> the user is not allowed. Now what: Close the connection? Or serve an
> error page?
>
>
Serve an error page.

.

>
> > I do have time ACLs, [...]
>
> The specifics of your ACLs are irrelevant at this stage. You can fix
> them later once you get overall SslBump setup working the way you want.
> You can assume that there is just one ACL called "prohibited_traffic" or
> "good_traffic". Now write the rules that determine what happens to
> connections that match one of those two ACLs.
>



>     If you want Squid to not intrude except when terminating prohibited
> >     traffic, then start with this sketch:
> >
> >       ssl_bump terminate prohibited_traffic
> >       ssl_bump peek all
> >       ssl_bump splice all
> >
> >
> > Lemme see if I understand this. I have a problem wrapping my head around
> > 'terminate' (as a terminology, maybe)
>
> "terminate" means "close the SSL connection(s) immediately". No error
> response is sent by Squid to the user. It does not get much simpler than
> that! The browser will probably show some "secure connection could not
> be negotiated" error to the user with no usable details [because Squid
> sent nothing to the browser in this case].
>
>
That is NOT what I want. I need squid to serve an error page that "Access
is denied at this time.."
I think it's usually something like "access controls prohibit you from
access this page at this time...".


>
> > and 'prohibited_traffic' (also as a terminology).
>
> Just some ACL name. You will define that aggregate ACL later to match
> any traffic you want to prohibit. It will contain a combination of time
> and server name ACLs. Other details are not important until your SslBump
> [and http_access rules] are correct.
>

Okay.


>
> If you do not know how to aggregate ACLs, look for "any-of" and "all-of"
> in squid.conf.documented, but, again, ACL specifics are not important
> right now. They will become important at stage three. Now you are
> struggling with stage one: Deciding what to do with matching SSL
> connections (close or serve error pages).
>

Sure, I am really struggling to understand this. I would like to serve
error pages. A complete example of this would really help. I am thinking,
based on the two templates you gave and going with the one where squid
intrudes, that it could be like below, but to be honest I am not sure so
kindly correct me.


acl time_wastage_sites_ssl ssl::server_name .facebook.com .youtube.com
ssl_bump splice time_wastage_sites_ssl
ssl_bump stare all
ssl_bump bump all
http_access allow time_wastage_sites_ssl privileged-staff
http_access allow time_wastage_sites_ssl privileged-clients
http_access allow time_wastage_sites_ssl TIMElunch
http_access allow time_wastage_sites_ssl TIMEafterhoursAFT
http_access allow time_wastage_sites_ssl TIMEafterhoursMORN
http_access allow time_wastage_sites_ssl TIMEsatALLDAY
http_access allow time_wastage_sites_ssl TIMEsundALLDAY
http_access deny  time_wastage_sites_ssl



>
> FWIW, my recommendation is to terminate/close and find other ways to
> inform users about their policy violations.





-- 
Best regards,
Odhiambo WASHINGTON,
Nairobi,KE
+254 7 3200 0004/+254 7 2274 3223
"Oh, the cruft."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20160422/d4c5993e/attachment-0001.html>