Filtering cipher suites and certificate algorithms without man-in-the-middle

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Filtering cipher suites and certificate algorithms without man-in-the-middle

Ali Galip Çamlı

Hi,

I've set up a firewall and proxy with pf & Squid on FreeBSD. 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?

My main goal is to avoid weak ciphers that parties agree upon. I want to force my clients to use modern algorithms while surfing on internet filtered by Squid.

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.

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

Sincerely,
Ali

Note: I already asked this question in https://serverfault.com/questions/987463/filtering-cipher-suites-and-certificate-algorithms-without-man-in-the-middlehttps://crypto.stackexchange.com/questions/74936/observing-cipher-suites-and-certificate-algorithms-without-man-in-the-middle


_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: 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.
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users