On 12/07/24 10:10, Alex Rousskov wrote:
On 2024-07-11 17:03, Amos Jeffries wrote:
On 11/07/24 00:49, Alex Rousskov wrote:
On 2024-07-09 18:25, Fiehe, Christoph wrote:
I hope that somebody has an idea, what I am doing wrong.
AFAICT from the debugging log, it is your parent proxy that returns
an ERR_SECURE_CONNECT_FAIL error page in response to a seemingly
valid "HEAD https://..."; request. Can you ask their admin to
investigate? You may also recommend that they upgrade from Squid v4
that has many known security vulnerabiities.
If parent is uncooperative, you can try to reproduce the problem by
temporary installing your own parent Squid instance and configuring
your child Squid to use that instead.
HTH,
Alex.
P.S. Unlike Amos, I do not see serious conceptual problems with
rewriting request target scheme (as a temporary compatibility
measure). It may not always work, for various reasons, but it does
not necessarily make things worse (and may make things better).
To which I refer you to:
None of the weaknesses below are applicable to request target scheme
rewriting (assuming both proxies in question are implemented/configured
correctly, of course). Specific non-applicability reasons are given
below for each weakness URL:
https://cwe.mitre.org/data/definitions/311.html
The above "The product does not encrypt sensitive or critical
information before storage or transmission" case is not applicable: All
connections can be encrypted as needed after the scheme rewrite.
Reminder, OP requirement is to cache the responses and send un-encrypted.
"can be" is not a safety measure.
https://cwe.mitre.org/data/definitions/312.html
The above "The product stores sensitive information in cleartext within
a resource that might be accessible to another control sphere." case is
not applicable: Squid does not store information in such an accessible
resource.
Reminder, Squid does cache both https:// and http:// traffic.
https://cwe.mitre.org/data/definitions/319.html
The above "The product transmits sensitive or security-critical data in
cleartext in a communication channel that can be sniffed by unauthorized
actors." case is not applicable: All connections can be encrypted as
needed after the scheme rewrite.
The relevant sensitive data is in the Responses, which are absolutely
transmitted un-encrypted per the OP requirements.
Cheers
Amos
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.squid-cache.org/listinfo/squid-users
