[squid-users] Filtering cipher suites and certificate algorithms without man-in-the-middle

[Alex Rousskov]

On 10/14/19 4:51 AM, Ali Galip Çamlı wrote:

> Is it
> possible to observe and filter with squid which cipher suite is selected
> between end points (client and server) without changing their SSL
> certificate, without mimicking server certificate?

It is possible to observe unencrypted handshake details, but you cannot
change anything without bumping.


> My main goal is to avoid weak ciphers that parties agree upon. 

You may be able to block TCP connections carrying cipher offers that
include "weak" ciphers, but a non-bumping Squid cannot remove a cipher
from the offered cipher list. IIRC, the mutually agreed upon cipher is
encrypted, even before TLS v1.3, so you would not be able to see it.


> For example, if client and server get on MD5 or SHA1, DES or RC4
> included cipher suite, or on SSLv3, or, if server sends my client a
> certificate signed with SHA1, or an expired certificate etc., I want to
> ban the traffic.

You can do some of the above using "ssl_bump peek/terminate" and/or
"http_access deny" rules. I am not sure there are built-in ACLs for
detecting all the handshake aspects you want to detect; you may have to
use an external ACL with various %ssl:... logformat codes and/or
%>handshake logformat code.


> There is a directive '*tls_outgoing_options*' in Squid and it has
> '*cipher*' and '*min-version*' configurations. Do these configurations
> satisfy my goal?

IIRC, no. That directive applies to TLS connections initiated by Squid,
not TLS connections tunneled by Squid.


HTH,

Alex.