[squid-users] Squid 2.7.s9 HTTPS-proxying - hint welcome
Torsten Kuehn
tekuehn at web.de
Wed Aug 17 23:00:41 UTC 2016
Thank you for your quick reply!
On 17/08/2016 6:01 p.m., Amos Jeffries wrote:
>> I am forced to stuck with 2.X
> Then you cannot decrypt the HTTPS in order to cache it. Squid older than
> 3.2 simply do not have any of the functionality to do so.
I.e. not cacheable at all? May sound stupid but I imagine layouts where the
encrypted traffic itself gets stored and a client could re-use it later.
But, most probably, session identifiers are unique, and the REQ-/ ACK-chains
during SSL/ TLS-negotiation are hardly reproducable. As Yuri Voinov
explained
earlier, new protocols were explicitly re-designed to suppress
MITM-handling.
At the beginning, I was so impressed by this new SSL & certificates stuff
that I did not notice significant differences between Squid releases.
> Cache is not an archive. Everything in a cache is by definition *not*
> valuable and subject to be erased at any time.
> [...] "of personal value" data is at high risk of being erased with
> every request sent through that proxy
Archiving is a different matter, no question. But I prefer not to erase
objects from my cache, unless requested. My refresh_patterns etc. may look
horrible for administrators who try to provide most recent content:
authenticate_ttl 359996400 seconds
hierarchy_stoplist cgi-bin
maximum_object_size 1073741824 bytes
refresh_pattern -i /cgi-bin/ 5258880 100% 5258880
refresh_pattern (Release|Packages(.gz)*)$ 0 20% 2880
refresh_pattern . 5258880 100% 5258880
override-expire override-lastmod ignore-no-cache ignore-private
positive_dns_ttl 359996400 seconds
negative_dns_ttl 60 seconds
vary_ignore_expire on
reload_into_ims on
This setup is that robust that both force-reload and PURGE fail unless
objects are deleted manually (resulting in "truncate: Warning: DosOpen
Error 110, OPEN_FAILED, file ...") or the ugly "reload_into_ims on" option
is set which violates standards.
>> is it possible that the cache objects' file format [unchanged] since 2.X
> some fundamental [...] changes to the swap.state journal format since 2.7.
> nothing serious - after upgrade Squid should discard the old swap.state
> file and do a "DIRTY" cache scan to rebuild the journal in the new format.
Sounds promising, thanks!
> objects themselves [...] just a simple TLV chain followed by the HTTP
> response object/payload. [...] testing is recommended
I'll try 3.5.19 as soon as GCC 5.2 libstdc++.so.6 for Raspbian is out.
Regards, Torsten
--
View this message in context: http://squid-web-proxy-cache.1019090.n4.nabble.com/Squid-2-7-s9-HTTPS-proxying-hint-welcome-tp4678986p4678997.html
Sent from the Squid - Users mailing list archive at Nabble.com.
More information about the squid-users
mailing list