Search squid archive

Re: How to tell HTTPS traffic is using cache from access.log in 3.5.x when using ssl_bump

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users




[Index of Archives]     [Linux Audio Users]     [Samba]     [Big List of Linux Books]     [Linux USB]     [Yosemite News]

  Powered by Linux