So just to illustrate the usage of : server_cert_fingerprint What this acl purpose is? Can it be documented? Also, There are more things regaring ssl bump bumping and certificates. 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? Let say I want to see the certificate and only then decide if it's valid for me. The best example is a Lets Encrypt certificates. These are valid technically but for a specific sites I would like to do something else. Also, can a tag be sent back from a sslcrtd_program?? I want to be able to do something with the certificate and response accordingly. I have a use case which I want to differentiate between general domain validation certificates to EV ones. Usually EV certificates are valid for PCI compliance and there for should not be bumped at all. For example: https://www.leumi.co.il/ Thanks, Eliezer ---- Eliezer Croitoru NgTech, Tech Support Mobile: +972-5-28704261 Email: ngtech1ltd@xxxxxxxxx -----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
