[squid-users] Forward loop when intercepting mode to proxy traffic to local VM

[jblank at twu.net]

To be honest, I am not 100% clear on Squid's various modes. If reverse 
proxy mode is capable of doing the decrypt/re-encrypt stuff, I'm fine 
with using it. Any pointers to HOWTOs or FAQs that might help?

Best,

Jessica

On Thu, 23 Jun 2016, Amos Jeffries wrote:

> On 22/06/2016 11:15 p.m., jblank wrote:
>> Slight correction on the Subject (my bad); I meant "when using intercept
>> mode", not "when intercepting mode".
>> 
>> On Wed, 22 Jun 2016, jblank wrote:
>> 
>>> Hey all,
>>>
>>> Thanks to a bizarre client requirement (don't ask, it's head-hurty), I
>>> am required to maintain a legacy server which only supports obsolete
>>> SHA-1 encryption. To keep things relatively safe, I'm attempting to
>>> contain the problem within a VM and use Squid on the VM's host to
>>> "re-encrypt" incoming traffic.
>>>
>>> That is:
>>> Outside world talks SHA2 to Squid; Squid internally talks SHA1 to the
>>> VM; Squid gets the response from the VM and passes it along
>>> (re-encrypting it to SHA2).
>
> Okay. That sounds simple. But the use of intercept implies things are a
> bit more complex for Squids situation.
>
> Is there a particular reason you are using interception?
>
> The next TLS / HTTPS stages of your task would be much less headache to
> do as a reverse-proxy.
>
>
>>>
>>> At least, that's the idea. But forget about SSL/encryption for the
>>> moment; I can't even get this concept working with plain old
>>> unencrypted HTTP.
>>>
>>> The VM is running locally, and accessible via host-only networking on
>>> 192.168.1.101. I set up a local /etc/hosts alternative JUST for
>>> Squid's use, which tells Squid that "myhost.mydomain.com" is actually
>>> 192.168.1.101. Yet Squid seems to be ignoring this. Incoming requests
>>> for http://myhost.mydomain.com/ throw a standard Squid "Access
>>> Denied." page. cache.log reveals the presence of a forward loop:
>>>
> <snip>
>
> Correct way to use a static link to a specific upstream is to use the
> cache_peer directive to tell Squid about that link and any fancy stuff
> about it.
>
> So this config should just work for both http:// and https:// traffic
> destined to the VM:
>
> # use the URL domain instead of raw-IPs
> acl VM_domains dstdomain example.com
> http_access allow VM_domains
>
> acl HTTPS proto HTTPS
>
> # The HTTP if you want it, remove these lines if not
> cache_peer 192.168.1.101 parent 80 0 originserver name=VM_http
> cache_peer_access VM_http allow HTTPS VM_domains
> cache_peer_access VM_http deny all
>
> # The HTTPS if you want it. Should work as-is but might need
> # other ssl* options for specific TLS/SSL tuning. see the TLS section
> # of http://www.squid-cache.org/Doc/config/cache_peer/ for details.
> cache_peer 192.168.1.101 parent 443 0 originserver ssl name=VM_https
> cache_peer_access VM_https allow !HTTPS VM_domains
> cache_peer_access VM_https deny all
>
>
> Note that Squid does not need hosts file entries for this to work.
>
> Also, the warning about forward proxy ports is because you dropped the
> default "http_port 3128" line. Add it back (or use reverse-proxy) and
> those will disappear.
>
>
> Cheers
> Amos
> _______________________________________________
> squid-users mailing list
> squid-users at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users