[squid-users] High CPU Usage with ssl_bump

Alex Rousskov rousskov at measurement-factory.com
Thu Apr 21 18:06:19 UTC 2016

On 04/21/2016 08:12 AM, Odhiambo Washington wrote:

> acl no_ssl_interception ssl::server_name ...
> ssl_bump splice no_ssl_interception 
> ssl_bump stare step2
> ssl_bump splice all

You are mixing splice and stare now. There are two groups of actions:

* peek and then splice
* stare and then bump

Do not mix actions from different groups together unless you know what
you are doing.

> So basically I should just have two options, I think, no?? Like
> ssl_bump stare step2
> ssl_bump splice all

Two bugs in this config:

1. It will splice everything during step #1. It is equivalent to:

   ssl_bump splice all

2. To quote the wiki page:

stare (step2): Receive server certificate while preserving the
possibility of bumping the connection. Staring at the server certificate
usually precludes future splicing of the connection.

squid.conf.documented has very similar text as well.

You are telling Squid to splice do exactly what the documentation tells
you is not usually possible.

I can understand that it may be difficult to find and interpret
documentation correctly. I can understand that it is difficult to
evaluate a given configuration correctly. What I cannot understand is
why you are not starting with configurations suggested specifically for
your use case, on this email thread.

> If one day, for some reason I want to bump, then I could change to:
> ssl_bump splice no_ssl_interception
> ssl_bump stare step2
> ssl_bump bump all

Similar to #1 above, this will bump all connections not matching the
[misnamed] no_ssl_interception during step1.

The first matching action wins. During step1, that action is "bump" from
your last rule if no_ssl_interception does not match.



More information about the squid-users mailing list