[squid-users] forward/reverse proxying with TLS.

[Tony Albers]

No, wait..

I think I'm actually in a position where use case #2 is relevant.

I know the origin server, actually there is only this single one.

I'll give it a try.

Thanks

On 13/04/2023 06:28, Tony Albers wrote:
> Hi Alex,
>
> Thanks for your answer. Too bad that squid can't do what I want.
>
> Can you think of another way of doing this, or do you know of another 
> tool that can?
>
> Thanks,
>
> /tony
>
> On 12/04/2023 15:55, Alex Rousskov wrote:
>> On 4/12/23 07:48, Tony Albers wrote:
>>
>>> What I want to do is "hide" an application behind squid, so that the 
>>> application receives http traffic, and sends http traffic. This 
>>> traffic then goes through squid in both directions, so that squid 
>>> receives https on the external IP and forwards it to the application 
>>> which is listening on the loopback interface, and squid receives 
>>> outgoing traffic from the application on the loopback interface and 
>>> then sends it out over the external IP with https.
>>
>>> Kinda like so:
>>> Incoming: exthost1(HTTPS)->thishostname:443-> squid 
>>> ->127.0.0.1(HTTP)->127.0.0.1:1080
>>>
>>> Outgoing: 127.0.0.1(HTTP)->127.0.0.1:8080-> squid
>>> ->exthost2:443(HTTPS)
>>
>>> when I use squid as outgoing proxy, the server in the other 
>>> end(88.24.12.40) says that squid doesn't present a client certificate
>>> and drops the connection.
>>
>> It looks like you are trying to force Squid to encrypt traffic by 
>> using tls_outgoing_options. Squid cannot be forced to encrypt. Squid 
>> encrypts if it needs to communicate with a TLS origin server or 
>> cache_peer and does not encrypt otherwise. The tls_outgoing_options 
>> directive is consulted _if_ Squid encrypts; it cannot _force_ 
>> encryption.
>>
>> There are two primary use cases where Squid should encrypt traffic on 
>> behalf of an HTTP application:
>>
>> 1. The application, when configured to use a proxy at http_port, 
>> sends Squid HTTP requests that have an "https" URL scheme. This is 
>> often referred to as "GET https" use case. Very few applications 
>> (i.e. HTTP user agents) do that, unfortunately.
>>
>> 2. The application, when configured to use a proxy at http_port, 
>> sends Squid HTTP requests that have an "http" URL scheme, and Squid 
>> is configured to forward those HTTP requests to one (or a few) 
>> cache_peers, each configured with "tls" and "originserver" options. 
>> This use case is applicable only if the application communicates with 
>> a few origin servers, and you know all those origin servers in 
>> advance (so that you can create a matching cache_peer configuration 
>> for each of them).
>>
>> If your use case is #2, then you need to adjust your cache_peer 
>> directive to make that cache_peer a TLS peer (with appropriate client 
>> certificates).
>>
>>
>> N.B. Your http_access rules may benefit from a refactoring that makes 
>> each rule specific to the listening port that needs access 
>> protection. For example, do not allow exthost traffic on http_port... 
>> Similar "everything everywhere" problem may exist for your cache_peer 
>> access rules: Those rules should deny peering for traffic received on 
>> https_port AFAICT.
>>
>>
>> HTH,
>>
>> Alex.
>>
>>
>>
>>> I have the application running in a container on the host.
>>> On the same host I also have squid installed.
>>>
>>> The application listens on 127.0.0.1:1080 on HOST
>>> Squid is set up as a reverse proxy, listening to https on the 
>>> external if on HOST:443 and forwards everything as http to 
>>> 127.0.0.1:1080
>>> (this works fine)
>>>
>>> When the application then transmits something via http, it uses 
>>> localhost:8080 as proxy, where squid picks it up and then forwards 
>>> it as https.
>>> (this doesn't work)
>>>
>>> At least that#s what I want it to do..
>>>
>>> However, when I use squid as outgoing proxy, the server in the other 
>>> end(88.24.12.40) says that squid doesn't present a client 
>>> certificate and drops the connection.
>>>
>>> But I got the impression that tls_outgoing_options is for exactly 
>>> that.. Have I misunderstood something?
>>>
>>>
>>> My squid config looks like this:
>>>
>>> # prefer DNS over IPv4
>>> dns_v4_first on
>>>
>>> # define hosts/networks that we use
>>> acl exthost src 88.24.12.60/32
>>> acl inthosts src 172.27.2.0/24
>>> acl internal src 127.0.0.1/32
>>>
>>> # access lists
>>> http_access allow exthost
>>> http_access allow inthosts
>>> http_access allow internal
>>>
>>> # reverse SSL proxy converting to noSSL
>>> https_port 172.27.2.118:443 accel
>>> tls-cert=/etc/squid/certs/thishostname.crt
>>> tls-key=/etc/squid/keys/thishostname-privkey.pem
>>> defaultsite=thishostname
>>> cache_peer 127.0.0.1 parent 1080 0 no-query proxy-only originserver 
>>> name=thishostname
>>>
>>> # forward proxy converting to SSL
>>> http_port 127.0.0.1:8080
>>> acl extnet dstdomain -n .somedomain.dk
>>> acl extip dstdomain 88.24.12.40
>>> acl intip dstdomain -n .someotherdomain.dk
>>> url_rewrite_program /etc/squid/urlrewrite.py
>>> tls_outgoing_options cert=/etc/squid/certs/thishostname.crt
>>> tls_outgoing_options key=/etc/squid/keys/thishostname-privkey.pem
>>> tls_outgoing_options cafile=/etc/squid/certs/thishostnameCA.pem
>>> tls_outgoing_options capath=/etc/ssl/certs
>>> tls_outgoing_options domain=somedomain.dk
>>> never_direct deny extnet
>>> never_direct deny extip
>>> never_direct allow all
>>>
>>> cache_peer_access thishostname allow exthosts
>>> cache_peer_access thishostname allow inthosts
>>> cache_peer_access thishostname allow internal
>>> cache_peer_access thishostname deny all
>>>
>>> # disable local caching
>>> cache deny all
>>
>> _______________________________________________
>> squid-users mailing list
>> squid-users at lists.squid-cache.org
>> http://lists.squid-cache.org/listinfo/squid-users
>
> _______________________________________________
> squid-users mailing list
> squid-users at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users