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@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
