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

[Amos Jeffries]

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