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

[Alex Rousskov]

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.