<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#464646" bgcolor="#FFFFFF">
<font face="monospace">Thanks Amos for this clarification,<br>
<br>
We also have the same needs and indeed, we face with the same
approach.<br>
<br>
It is possible that the structure of Squid could not, in some
cases, recovering this type of information.<br>
Although the concept of a proxy is neither more nor less than a
big browser that surfs instead of the client browsers.<br>
<br>
The SHA1 and certificate information reception are very valuable
because it ensures better detection of compromised sites (many
malicious sites use the same information in their certificates).<br>
This allows detecting "nests" of malicious sites automatically.<br>
<br>
Unfortunately, there is madness in the approach to security, there
is a race to strengthen the security of tunnels (produced by
Google and browsers vendors).<br>
What is the advantage of encrypting wikipedia and Youtube
channels?<br>
<br>
On the other hand, it is crucial to look inside these streams to
detect threats.<br>
This is antinomic...<br>
<br>
So TLS 1.3 and soon the use of QUIC with UDP 80/443 will make use
of a proxy useless as these features are rolled out (trust Google
to motivate them)<br>
Unless the proxy manages to follow this protocol madness race...<br>
<br>
For this reason, firewall manufacturers propose the use of client
software that fills the gap of protocol visibility in their
gateway products or you -can see a </font><font face="monospace"><font
face="monospace">growth of workstation</font> protections , such
EDR concept<br>
<br>
Just an ideological and non-technical approach...<br>
<br>
Regards<br>
</font><br>
<div class="moz-cite-prefix">Le 19/11/2022 à 16:50, Amos Jeffries a
écrit :<br>
</div>
<blockquote type="cite"
cite="mid:19ae1da5-5d0a-93d6-e91f-3e82b064b1ed@treenet.co.nz">On
19/11/2022 2:55 am, UnveilTech - Support wrote:
<br>
<blockquote type="cite">Hi Amos,
<br>
<br>
We have tested with a "ssl_bump bump" ("ssl_bump all" and
"ssl_bump bump sslstep1"), it does not solve the problem.
<br>
According to Alex, we can also confirm it's a bug with Squid 5.x
and TLS 1.3.
<br>
</blockquote>
<br>
Okay.
<br>
<br>
<blockquote type="cite">It seems Squid is only compatible with TLS
1.2, it's not good for the future...
<br>
</blockquote>
<br>
One bug (or lack of ability) does not make the entire protocol
"incompatible". It only affects people trying to do the particular
buggy action.
<br>
Unfortunately for you (and others) it happens to be accessing this
server cert fingerprint.
<br>
<br>
I/we have been clear from the beginning that *when used properly*
TLS/SSL cannot be "bump"ed - that is true for all versions of TLS
and SSL before it. In that same "bump" use-case the server does
not provide *any* details, it just rejects the proxy attempted
connection. In some paranoid security environments the server can
reject even for "splice" when the clientHello is passed on
unchanged by the proxy. HTTPS use on the web is typically
*neither* of those "proper" setups so SSL-Bump "bump" in general
works and "splice" almost always.
<br>
<br>
Cheers
<br>
Amos
<br>
<br>
_______________________________________________
<br>
squid-users mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:squid-users@lists.squid-cache.org">squid-users@lists.squid-cache.org</a>
<br>
<a class="moz-txt-link-freetext" href="http://lists.squid-cache.org/listinfo/squid-users">http://lists.squid-cache.org/listinfo/squid-users</a>
<br>
</blockquote>
</body>
</html>