On 28/01/2017 1:32 p.m., Charlie Orford wrote: > On 27/01/2017 23:43, Alex Rousskov wrote: >> On 01/27/2017 04:04 PM, Charlie Orford wrote: >>> A post from another user on this list seems to suggest they successfully >>> got squid to do what we want >>> (http://lists.squid-cache.org/pipermail/squid-users/2015-November/007955.html) >>> >>> but when emulating their setup (i.e. peeking at step1, staring at step2 >>> and then bumping at step3) we get the same >>> SQUID_X509_V_ERR_DOMAIN_MISMATCH error. >> I suggest the following order: >> >> 1. Decide whether your Squid should bump or splice. >> 2. Find the configuration that does what you decided in #1. >> >> So far, you have given no reasons to warrant bumping so I assume you do >> not need or want to bump anything. Thus, you should ignore any >> configurations that contain "stare", "bump", or deprecated "*-first" >> ssl_bump actions. > > Sorry if my original intent wasn't clear. Obviously it makes no sense > intercepting ssl traffic if we're going to splice everything. > > Our design goal is: intercept and bump local client https traffic on > squid1 (so we can filter certain urls, cache content etc.) and then > forward the request on to the origin server via an upstream squid2 > (which has internet access). Under a narrow set of splice conditions you can get traffic through the 2-proxy heirarchy. But that is a very limited set of circumstances and definitely not working with 'bump' anywhere involved. As Alex pointed out step3 also eliminates the CONNECT ability. Which I was not aware of a year ago when I wrote that original email you referenced. The problem is that *any* server or peer TLS communication prior to deciding to splice eliminates the ability to use a fake-CONNECT. That is absolute because *all* TLS server/peer communication has to go through the CONNECT tunnel - or none can. Anything happening prior to its existence wont be TLS authenticated with the origin server. > > The user who posted > http://lists.squid-cache.org/pipermail/squid-users/2015-November/007955.html > seems to have successfully done this but I can't replicate it. After They did not because Squid _cannot_ do it. Note that their cache_peer has 'ssl' flag enabled. So their transparent traffic is using the peer certificate to base the auto-generated certs on. Which you already tried and decided was not workable for you. Amos _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
