On 30/03/2016 9:43 a.m., Baselsayeh wrote: > sorry > it seems that http://squid-web-proxy-cache.1019090.n4.nabble.com doesnt > remove posts This is an email mailing list. Nabble is just an archive display. There is no "oops I should not have mailed the world" undo feature in email. > > Yuri Voinov wrote > I said exactly: "Cache peer cannot use re-crypting right now". > > No matter what do you have behind cache_peer. Correction: Squid does not (yet) support re-"CONNECT" messaging to cache_peer. It certainly does support TLS connections to upstream peers. When bumping it *requires* that the peer supports TLS connections. Which is part of the problem lots of people have sending bumped data onwards to non-TLS peers. > > 30.03.16 2:40, Baselsayeh пишет: >>>> is there a workaround that i can use cache peer and squid sslbump? >>>> isnt stunnel is using ssl that squid dont need to re-crypting? >>>> I think your main problem is that Squid *is* re-crypting the outbound connection to stunnel. Then stunnel is double-crypting it since stunnel purpose is to encrypt plain-text connections. When the tunnel made by stunnel through the privoxy-like thing reaches whatever destination Squid instructed it to contact it gets decrypted _once_ and the data inside is found to be encrypted ... oops. What you need to avoid this is something like httptunnel. Which does not double-encrypt the traffic. PS. the tutorials you see around the Internet about using Squid + stunnel at present are either to take plain-text client connections and send them through stunnel to a secured https_port on Squid. Or to take outbound connections from a non-encrypting Squid and send them securely to some upstream proxy. Amos _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
