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