[squid-users] seeking assistance for home users wanting to cache https contents
squid3 at treenet.co.nz
Thu Sep 3 02:10:31 UTC 2020
On 1/09/20 6:52 am, Michael Davis wrote:
> •The github repo is actually for refresh patterns specifically
> •I extensively read over almost every squid wiki page, but unfortunately
> my attempts to understand them felt kind of useless, i did read likely
> well over fifty different attempts guides, and found myself realizing to
> your point, most info IS highly outdated
> •my config for everything is fine so far, so we can ignore pfsense snd
> things unrelated to squid safely, thank heavens for that one
> • as far as i can tell, squid is properly?? Caching non ssl delivered
> contents *disclaimer, i am fully guessing on this one* it shows bulk
> access logs of tcp_miss/200 | tcp_tunnel/200 | tcp_inm_hit/200 |
> none/200 real time results
Okay. So some HTTP(S) is happening.
You can possibly do some finer grain tests to see which of these are for
regular http:// requests by the Browser and which are for https://
traffic. That is, checking to see which of port 80 and 443 got
intercepted and how the log looks from that.
> • "FYI, "proper" caching has nothing to do with SSL-Bump.
> Separate any changes you want in relation to caching from the SSL-Bump
> changes. Test each set of changes independently to get one feature going
> before you move on to the other." ...... much as i don't want to admit
> this, THAT should have been obvious, but i think i might have over
> looked that fact....
> ● "So what I am understanding from your description is that you are
> trying to:
> A) intercept traffic with pfsense
> B) SSL-Bump the TLS which arrives at the proxy
> C) cache the decrypted HTTP messages
> Is that correct?" THAT is exactly what my goals are, yes.
> • as for that bare bones config example, that's exactly what im using
> right now, but admittedly im not knowledgeable enough to fully and
> confidently tell if it's working at this point, i feel it isnt however
IIRC SSL-Bump traffic from that minimal test ssl_bump config should log
as one NONE/200 [if I remember wrong this might be TCP_TUNNEL/200] with
"CONNECT raw-IP:port" (the "peek" happening) followed by a
TCP_TUNNEL/200 (the "splice") with "CONNECT domain:port" - depending on
client sending TLS SNI.
Squid does not have any part in the TLS handshakes for that minimal
config, so any TLS errors are between the client and origin server.
If that all checks out as what you are seeing. Adding a "stare step2"
instead of splice, and a "bump all" final line starts Squid decrypting.
You should see the two CONNECT transactions mentioned above will still
be logged, maybe a third one as well from the "stare" with updated
domain name from the server cert. But the main sign of bump happening is
that log now also contains normal GET/POST etc lines where the URL
starts with "https://" scheme.
More information about the squid-users