On 3/30/22 03:27, Eliezer Croitoru wrote:
So just to illustrate the usage of :
server_cert_fingerprint
What this acl purpose is? Can it be documented?
Please see squid.conf.documented for the best available answers to those
two questions. If something is not clear in that documentation, please
ask more specific questions. If my answers clarified something for you,
consider submitting a pull request that improves existing documentation.
Is it possible today to decide whether to bump or not a connection
based on some part of the certificate, else then the sni or domain?
Yes, to a certain extent: After Squid saw the server certificate, it is
too late to make a bump-vs-splice decision, but it is still possible to
make a decision to either continue with the previously implicitly
decided action (bump or splice, depending on whether step2 action was
stare or peek) or close the TCP connections (i.e. apply the "terminate"
action).
In other words, after seeing the server certificate, Squid can make a
continue-vs-terminate decision but not a splice-vs-bump decision.
This is how TLS works. The only known alternative is to use a second,
"probing" TLS connection to the origin server. Squid does not support
that alternative natively yet, but there is a constant trickle of
requests for that feature, especially given TLS v1.3 encryption of
certificates that effectively places them outside the peek/stare actions
reach.
Also, can a tag be sent back from a sslcrtd_program??
IIRC, not yet, but we are working on adding that functionality to the
sslcrtvalidator_program. If extending that addition to both programs is
easy, we will do that.
HTH,
Alex.
-----Original Message-----
From: Alex Rousskov <rousskov@xxxxxxxxxxxxxxxxxxxxxxx>
Sent: Wednesday, January 27, 2021 22:07
To: squid-users@xxxxxxxxxxxxxxxxxxxxx
Cc: Eliezer Croitoru <ngtech1ltd@xxxxxxxxx>
Subject: Re: acl aclname server_cert_fingerprint
On 1/27/21 1:50 PM, Eliezer Croitoru wrote:
I am still missing a way to make this work with the fingerprint.
I do not know what you are trying to accomplish (i.e. what "this" is).
We first need to know the fingerprint but when squid "knows" about
it, it's already too late. In what config scenario can it work?
Knowing the fingerprint (or any other server-sent detail!) is indeed not
useful for making bump-vs-splice decisions. Fingerprint knowledge can be
useful for many other decisions, including whether to allow an HTTP
request, whether to cache an HTTP response, and whether to terminate a
TLS connection.
HTH,
Alex.
-----Original Message-----
From: Alex Rousskov <rousskov@xxxxxxxxxxxxxxxxxxxxxxx>
Sent: Wednesday, January 27, 2021 8:43 PM
To: squid-users@xxxxxxxxxxxxxxxxxxxxx
Cc: Eliezer Croitoru <ngtech1ltd@xxxxxxxxx>
Subject: Re: acl aclname server_cert_fingerprint
On 1/27/21 11:45 AM, Eliezer Croitoru wrote:
I'm not sure I understood hat these errorcde and error detai.
FWIW, access log fields are configured using logformat %codes. Search
squid.conf.documented for the words "err_code" and "err_detail" (no quotes).
acl tls_to_splice any-of ... NoBump_certificate_fingerprint
acl tls_s1_connect at_step SslBump1
acl tls_s2_client_hello at_step SslBump2
ssl_bump peek tls_s1_connect
ssl_bump splice tls_to_splice
ssl_bump stare tls_s2_client_hello
ssl_bump bump tls_to_bump
Bugs notwithstanding, the NoBump_certificate_fingerprint ACL will never
match in the above configuration AFAICT:
* step1 is excluded by the earlier "peek if tls_s1_connect" rule. The
server certificate is not yet available during that step anyway.
* step2 is reachable for a "splice" action, but the server certificate
is still not yet available during that step.
* step3 is unreachable for a "splice" action because the only non-final
action during step2 is "stare". Starting precludes splicing.
HTH,
Alex.
-----Original Message-----
From: Alex Rousskov <rousskov@xxxxxxxxxxxxxxxxxxxxxxx>
Sent: Wednesday, January 27, 2021 5:12 PM
To: Eliezer Croitoru <ngtech1ltd@xxxxxxxxx>; squid-users@xxxxxxxxxxxxxxxxxxxxx
Subject: Re: acl aclname server_cert_fingerprint
On 1/26/21 2:09 AM, Eliezer Croitoru wrote:
I'm trying to understand what I'm doing wrong in the config that stil
lets edition.cnn.com be decrypted instead of spliced?
If you still need help, please share the relevant parts of your
configuration and logs. I would start with ssl_bump rules and access log
records containing additional %error_code/%err_detail fields.
Alex.
-----Original Message-----
From: Alex Rousskov <rousskov@xxxxxxxxxxxxxxxxxxxxxxx>
Sent: Tuesday, January 26, 2021 6:22 AM
To: Eliezer Croitoru <ngtech1ltd@xxxxxxxxx>; squid-users@xxxxxxxxxxxxxxxxxxxxx
Subject: Re: acl aclname server_cert_fingerprint
On 1/25/21 6:03 AM, Eliezer Croitoru wrote:
I'm trying to use:
acl aclname server_cert_fingerprint [-sha1] fingerprint
I have cerated the next file:
/etc/squid/no-ssl-bump-server-fingerprint.list
And trying to use the next line:
acl NoBump_certificate_fingerprint server_cert_fingerprint -sha1
"/etc/squid/no-ssl-bump-server-fingerprint.list"
To be explicit despite that only sha1 is a valid checksum.
Squid doesn't accept the above line
Does not accept how? What is the error message?
but this one yes:
acl NoBump_certificate_fingerprint server_cert_fingerprint
"/etc/squid/no-ssl-bump-server-fingerprint.list"
Is there a reason for that?
The use of ACL options and ACL parameter options is poorly documented.
Squid Bug 4847 is marked as fixed, but the corresponding commit d4c6aca
says that server_cert_fingerprint is still broken. Not sure whether that
was true, whether some other commit has fixed that ACL, and whether the
problem mentioned in the commit message is related to your troubles.
https://bugs.squid-cache.org/show_bug.cgi?id=4847
https://github.com/squid-cache/squid/pull/191
Also, according to my 2015 notes, server_cert_fingerprint happens to be
case sensitive. I consider that a bug. I am not sure, but I think Squid
expects uppercase hex letters (if any). I do not know whether that has
been fixed.
Finally, it is dangerous to list ACL parameter options like -sha1 in
front of parameter filename when that parameter file may contain its own
parameter options. A reader may think that -sha1 in squid.conf
overwrites, say, -sha256 in the parameter file, but that is not what
probably will happen when Squid starts supporting both options.
That consideration may actually be the reason why Squid rejects your
first configuration sample (or perhaps it should be the reason even if
it does not).
I am sure there are use cases where the admin wants to apply one
parameter option to the whole file, but the ambiguity is too dangerous
to allow IMO. We should make the choice explicit.
HTH,
Alex.
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
