[squid-users] Clarity on sending intercepted HTTPS traffic upstream to a cache_peer

[Amos Jeffries]

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