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
