Search squid archive

Re: Rewriting HTTP to HTTPS for generic package proxy

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux Audio Users]     [Samba]     [Big List of Linux Books]     [Linux USB]     [Yosemite News]

  Powered by Linux