[squid-users] How to tell HTTPS traffic is using cache from access.log in 3.5.x when using ssl_bump

[Lei Wen]

Hi Amos,

*Squid does not support relaying decrypted https:// requests over an
> insecure connection. So HTTP cache_peer connections will be refused.*

Do you mean HTTPS cache_peer connections will be refused?


*Also, when TLS cache_peer is used Squid is unable to tell the difference
> between the peer TLS server details an origin. So any server-cert forging
> uses the cache_peer's server cert instead of the origin.*
>
I am using the same cert on every host, so it doesn't matter if it picks
the peer's cert. Besides, I have all sibling relation in this pool, only
parent will start the request for peer, right?



> *In Squid-3.5 (and v4) explicit/forward proxy it is best not to use
> cache_peer for decrypted content. The most working way for now is to let it
> go 'DIRECT' and repeat the intercept at the peer.*

Which directive do you mean by 'DIRECT' as a replacement of cache_peer?


My setup doesn't have many layers like a CARP cluster, it's just a squid
host pool, and they are all siblings with each other, no
parent/frontend/backend concept, each squid host is also a container host,
all containers on different host are doing similar job, so they can share
cache between different hosts. This is our initial idea for this project if
you know there are better hierarchy and can give me some suggest I am
really appreciate.



Thanks,
Lei


On Wed, Jul 26, 2017 at 3:30 PM, Amos Jeffries <squid3 at treenet.co.nz> wrote:

> On 27/07/17 09:54, Lei Wen wrote:
>
>> Hi Amos,
>>
>> Thanks a lot.
>> It is my splice thing is blocking proxy in the middle,
>>
>
> Sort of, yes.
>
> after using stare instead of peek, seems work though, terminal in this
>> case is not blocking proxy in the middle?
>>
>>
> Not sure what you are asking there. Squid *is* the proxy in the middle, so
> terminate does a TCP close().
>
>
> I made some change on my squid.conf, it work for http/https caching and
>> http/https whitelist.
>> It is working for http sibling cache as well, but has some issue with
>> https/ssl sibling cache.
>> in cache_peer, which port number should I use as forward-proxy port?
>> 3130/3128/3129?
>>
>
> Squid does not support relaying decrypted https:// requests over an
> insecure connection. So HTTP cache_peer connections will be refused.
>
> Also, when TLS cache_peer is used Squid is unable to tell the difference
> between the peer TLS server details an origin. So any server-cert forging
> uses the cache_peer's server cert instead of the origin.
>
> In Squid-3.5 (and v4) explicit/forward proxy it is best not to use
> cache_peer for decrypted content. The most working way for now is to let it
> go 'DIRECT' and repeat the intercept at the peer.
>
>
>
>> I am trying to set up a sibling cache pool, there is no parent or gateway
>> sort of thing in this hierarchy.
>> Each instance can have their own whitelist, but they share the same cache
>> pool.
>> On each instance host, squid is actually doing it's whitelist and caching
>> job for a container group on the same host.
>>
>>
> Are you trying to describe something like a CARP hierarchy?
> <http://wiki.squid-cache.org/ConfigExamples/SmpCarpCluster>
>
> They suffer from the above problem. There is no good solution for that in
> current Squid versions which do SSL-Bump.
>
>
>
>> acl step1 at_step SslBump1
>> acl step2 at_step SslBump2
>> acl step3 at_step SslBump3
>> ssl_bump stare step1 all
>> ssl_bump stare step2 allowed_https_sites
>> #ssl_bump bump step3
>> ssl_bump terminate step2 all
>>
>>
>
> Up to you, but I would do this:
>
>  ssl_bump peek step1
>
>  ssl_bump stare step2 allowed_https_sites
>  ssl_bump terminate step2
>
>  # decrypt with server-cert forging
>  ssl_bump bump step3
>
>
> That peek at step1 allows Squid can splice if things to badly at the step2
> staring. A peek at step1 will not prevent a step3 bump.
>
> And the explicit line with 'bump' ensures that Squid actually does a bump,
> the default behaviour is a little bit too variable depending on what bugs
> are present in the SSL-Bump code.
>
>
> Amos
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20170727/56ea2859/attachment.html>