I do not know what you are trying to accomplish (i.e. what "this" is).
> it, it's already too late. In what config scenario can it work?
useful for making bump-vs-splice decisions. Fingerprint knowledge can be
> -----Original Message-----
> From: Alex Rousskov <
[hidden email]>
> Sent: Wednesday, January 27, 2021 8:43 PM
> To:
[hidden email]
> Cc: Eliezer Croitoru <
[hidden email]>
> Subject: Re: [squid-users] 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 <
[hidden email]>
>> Sent: Wednesday, January 27, 2021 5:12 PM
>> To: Eliezer Croitoru <
[hidden email]>;
[hidden email]
>> Subject: Re: [squid-users] 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 <
[hidden email]>
>>> Sent: Tuesday, January 26, 2021 6:22 AM
>>> To: Eliezer Croitoru <
[hidden email]>;
[hidden email]
>>> Subject: Re: [squid-users] 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
>>>
[hidden email]
>>>
http://lists.squid-cache.org/listinfo/squid-users>>>
Locked
squid.conf (7K)