[squid-users] Squid ssl_bump configuration optimized for highest CPS?

[Amos Jeffries]

On 11/11/2022 5:38 am, Andralojc, Wojciech wrote:
>
> Hi,
>
> I’m running squid v4.13 in TLS bump mode.
>
> Trying to configure it to get highest (single core) CPS (new TLS 
> sessions/connections per second) numbers.
>
> I run multiple s_time tests on client side and “plain” nginx on server 
> side.
>
> Example s_time command line:
>
> openssl s_time -connect server:443 -new -cipher AES128-GCM-SHA256 
> -time 30 -CAfile /opt/proxy_rootCA.pem -tls1_2
>
> Could you please review config below and suggest changes to improve 
> performance?
>

FYI; If this config you have shown is intended to go into production, 
then I would suggest not using Squid at all.
Without logging, decryption, nor policy rules there is no benefit to 
using Squid.

You would have better efficiency using NAT to redirect the traffic.


> Assumptions:
>
>   * SSL bump/transparent SSL proxy;
>

Which definition of "transparent" do you mean exactly?
  * The HTTP definition where it means a proxy does not alter the traffic?
  * or the colloquial use where it means intercepting and filtering traffic?

Your provided config looks like it is trying to do both.

>  *
>
>
>   * single core performance;
>   * caching disabled;
>   * persistent connections disabled;
>   * no logs;
>

The last three of those assumptions are debatable.

* the use of a proxy naturally adds some amount of latency to traffic. 
Caching is one of the major mechanisms used in HTTP to counter this cost 
and when possible exceed it for extra performance. Whether it is useful 
depends on how much (if any) of your traffic is cacheable.

* persistence connections are how HTTP (and HTTPS) avoid TCP connection 
setup latency costs. Disabling is generally a loss of performance, but 
some specific situations can benefit from it.
One of the things you should absolutely do is test is what impact 
persistence has on your proxy performance, on each of the client/server 
connection types independently.

* logging is a very minor impact. Processing the HTTP messages is by far 
the largest part of Squid performance costs.
That said;
   - store.log is almost always useless so that is OFF by default nowdays.
   - access.log is minor work, it can be disabled for a trivial 
reduction in CPU cycles at cost of not being able to see what clients 
are doing with the proxy.


> http_access deny !Safe_ports
>
> http_access deny CONNECT !SSL_ports
>
> http_access allow localhost manager
>
> http_access deny manager
>
> http_access allow localnet
>
> http_access allow localhost
>
> http_access allow all
>

You now have an open-proxy.


> # Squid normally listens to port 3128
>
> http_port 3128
>
> http_port 3129 intercept
>
> ssl_bump server-first all
>

"server-first" is deprecated.
Instead please use the new syntax:

   acl step1 at_step SslBump1
   ssl_bump peek step1
   ssl_bump splice all

> https_port 3130 intercept ssl-bump cert=/etc/ssl/certs//rootCA.pem 
> generate-host-certificates=on
>


> visible_hostname "proxy"
>

This should be an externally resolvable FQDN and not quoted.

> tls_outgoing_options cafile=/etc/ssl/certs//nginx.pem
>
> access_log none
>
> cache_store_log none
>

Not needed, cache_store_log default is disabled anyway.

> cache_log /dev/null
>

cache_log is not optional. If Squid has problems serving traffic that is 
your only source of information about what happened.
To minimize what gets logged use this instead:

   debug_options ALL,0

> workers 1
>

If you have a multi-core machine this is not enough. You may also need 
CPU affinity to lock the Squid processes to one core.
see <http://www.squid-cache.org/Doc/config/cpu_affinity_map/>


> cache deny all
>
> cache_mem 0
>

Okay, but if you have any plain-text or decrypted messages handled by 
Squid at least some memory cache can have performance benefits.
This is something you should definitely test, measure, tune to see what 
works best on your specific traffic.

> server_persistent_connections off
>
> client_persistent_connections off
>

See above.


HTH
Amos