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

[Tony Albers]

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