[squid-users] Squid cache with SSL

[Amos Jeffries]

On 25/05/20 8:09 pm, Andrey Etush-Koukharenko wrote:
> Hello, I'm trying to set up a cache for GCP signed URLs using squid 4.10
> I've set ssl_bump:
> *http_port 3128 ssl-bump cert=/etc/ssl/squid_ca.pem
> generate-host-certificates=on dynamic_cert_mem_cache_size=4MB
> 
> sslcrtd_program /usr/lib/squid/security_file_certgen -s /var/lib/ssl_db
> -M 4MB
> 
> acl step1 at_step SslBump1
> 
> ssl_bump peek step1
> ssl_bump bump all*

The above SSL-Bump configuration tries to auto-generate server
certificates based only on details in the TLS client handshake. This
leads to a huge number of problems, not least of which is completely
breaking TLS security properties.

Prefer doing the bump at step3,


> *
> I've set cache like this:
> 
> *refresh_pattern -i my-dev.storage.googleapis.com/.* 
> 4320 80% 43200 override-expire ignore-reload ignore-no-store ignore-private*
> *

FYI: that does not setup the cache. It provides *default* parameters for
the heuristic expiry algorithm.

* override-expire replaces the max-age (or Expires header) parameter
with 43200 minutes from object creation.
  This often has the effect of forcing objects to expire from cache long
before they normally would.

* ignore-reload makes Squid ignore requests from the client to update
its cached content.
 This forces content which is stale, outdated, corrupt, or plain wrong
to remain in cache no matter how many times clients try to re-fetch for
a valid response.

* ignore-private makes Squid content that is never supposed to be shared
between clients.
 To prevent personal data being shared between clients who should never
see it Squid will revalidate these objects. Usually different data will
return, making this just a waste of cache space.

* ignore-no-store makes Squid cache objects that are explicitly
*forbidden* to be stored in a cache.
  80% of 0 seconds == 0 seconds before these objects become stale and
expire from cache.

Given that you described this as a problem with an API doing *signing*
of things I expect that at least some of those objects will be security
keys. Possibly generated specifically per-item keys, where forced
caching is a *BAD* idea.

I recommend removing that line entirely from your config file and
letting the Google developers instructions do what they are intended to
do with the cacheability. At the very least start from the default
caching behaviour and see how it works normally before adding protocol
violations and unusual (mis)behvaviours to how the proxy caches things.


> *
> In the cache directory, I see that object was stored after the first
> call, but when I try to re-run the URL I get always
> get: *TCP_REFRESH_UNMODIFIED_ABORTED/200*

What makes you think anything is going wrong?

 Squid found the object in cache (HIT).
 The object requirements were to check with the origin server about
whether it could still be used (HIT becomes REFRESH).
 The origin server said it was fine to deliver (UNMODIFIED).
 Squid started delivery (status 200).
 The client disconnected before the response could be completed delivery
(ABORTED).

Clients are allowed to disconnect at any time, for any reason.


Amos