[squid-users] Rewriting HTTP to HTTPS for generic package proxy

[Alex Rousskov]

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.


> 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.


> 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.

Alex.