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

[Amos Jeffries]

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