On 06/04/18 20:02, j.emerlik wrote: > On Thu, Apr 5, 2018, 23:44 Amos Jeffries wrote: > > On 06/04/18 08:56, j.e. wrote: > > (squid 3.5) I have in my config acl for some domains like: > > > > acl mydomains dstdomain "/usr/local....." > > > > and > > > > cache_peer_access 10.10.x.x allow mydomains > > > > so all http traffic to domains from my list is forwarded (port 80) to > > another squid and that's works correct but only for port 80, > traffic to > > port 443 does work probably because there in config is set: > > > > allways_direct allow SSL_ports > > > > and forwarding to my another squid not working. > > How is your cache_peer directive setup? > > It is more likely because your peer is not setup to receive HTTPS > traffic, so the "mydomains" stuff is not going where you may think. > > Amos > > > Thx for response , below part of my config : > > cache_peer 10.10.x.x parent 31281 0 proxy-only no-tproxy > > acl mydomains dstdomain "use/local....." > > cache_pee_access 10.10.x.x allow mydomain > > never_direct allow mydomain > > peer_connect_timeout 5 seconds > Okay. So normal forward-proxy setup. If the port 443 traffic is being intercepted then SSL-Bump'ed, then Squid requires that cache_peer connection to be using TLS/SSL in order to deliver it there. For that this Squid requires the 'ssl cafile=' options, with the CA one pointing to a PEM file containing public cert of the CA which signed the peers server certificate. The peer of course requires its listening port (or another) to have TLS setup at its end, and appropriate security setting for its own outbound connections. Other non-bumped traffic and CONNECT messages should "just work" already. [ While TLS being end-to-end is a myth, Squid and most TLS software still do ensure the whole connection chain stays secured. So no conversions from HTTPS to HTTP in either direction along the way. ] Amos _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
