On 2024-07-15 17:19, Amos Jeffries wrote:
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.
The client does not support TLS so what happens between the client and
Squid is irrelevant to this discussion -- a correctly
configured/implemented Squid is not going to make things worse there.
Squid is a part of the "product" in the above definition; client is not.
The only relevant communication part is between Squid and origin server
(possibly via a parent). All those network segments can be configured to
be encrypted "before storage or transmission", avoiding the above weakness.
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.
I do not see how that assertion is relevant. Everything Squid caches is
_not_ stored in an "accessible resource" described in that weakness.
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.
See 311.html case above: Responses are encrypted on the relevant network
segments.
Alex.
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.squid-cache.org/listinfo/squid-users
