On 05/28/2017 05:40 AM, Vieri wrote: > Please keep in mind that I'm basically an end-user, a sys-admin. I > wish I had the time to study Squid's source code. Nobody (certainly not me) has suggested anything that requires studying Squid source code. If you think that I have, you have misinterpreted what I have said. > The cache log reports errors but they are not necessarily related to > this client as there are many others actively browsing. I recommend triaging this using a Squid instance isolated from all other traffic. You are making both your job and the job of those who are trying to help you more difficult by trying to save a few minutes/hours that are usually required to set up an isolated test. > Anyway, as a workaround I'm willing to splice/tunnel traffic to > accounts.google.com *ONLY*, and bump everything else (although I'd > prefer to understand why bumping isn't "working" for this site). > I've tried this: > acl GoogleAccounts ssl::server_name accounts.google.com > acl step1 at_step SslBump1 > ssl_bump peek step1 > ssl_bump splice GoogleAccounts > ssl_bump bump all > However, traffic to accounts.google.com is not spliced, it's bumped > like the rest. You need to figure out why. Two common reasons are SSL-level errors and http_access denials. Both should be reflected in access.log and debugging cache.log. > Can FQDNs be used in ACLs as in the example above even when peeking at step 1? Yes. They may not work, but they can be used. They should work if the request contains TLS SNI. Modern browser requests usually do, but you can confirm by studying browser-Squid traffic with a tool like Wireshark. > If I peek at step 2 then I won't be able to "bump all" Correct. > Likewise, If I need to stare at step 2 then I'll never be able to splice Correct. Alex. _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
