[squid-users] High CPU Usage with ssl_bump

Alex Rousskov rousskov at measurement-factory.com
Thu Apr 21 23:16:50 UTC 2016

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".

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

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

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?

> 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].

> 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.

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).

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


More information about the squid-users mailing list