Alex, So what do you recommend to do here ? I just need a simple whitelist file for both http/https. I have a config that works on 3.4 but would like to upgrade to 3.5 and the current config we have won't cut it. Just need a simple if you are in this list allow if not deny. No need for any ssl validation or anything. > On Oct 21, 2015, at 6:49 PM, Alex Rousskov <rousskov@xxxxxxxxxxxxxxxxxxxxxxx> wrote: > >> On 10/21/2015 02:49 PM, Yuri Voinov wrote: >> >> Working config snippet for 3.5.x looks like this: >> >> ssl_bump peek get_sni_at_step1 >> ssl_bump splice spliced_hosts >> ssl_bump bump net_bump > > > The above config leaves the following question unanswered: > > Q: What happens if neither spliced_hosts nor net_bump match at bumping > step #2? > > > Leaving questions unanswered is a bad idea for ssl_bump rules because > defaults are complex (and used to be broken). To answer that question > (instead of forcing Squid to guess the answer), add a forth catch-all > rule. For example, this is how the latest Squids would guess: > > ssl_bump peek step1 > ssl_bump splice spliced_hosts > ssl_bump bump net_bump > ssl_bump splice all > > > If spliced_hosts ACL negation works reliably, then the above is > equivalent to: > > ssl_bump peek step1 > ssl_bump bump !spliced_hosts net_bump > ssl_bump splice all > > but I recommend avoiding ACL negation in the actual rules. > > > Finally, please make sure your http_access rules correctly handle > CONNECT requests (real for forwarded connections and fake ones for > intercepted connections). This may be difficult to do right now due to > bug 4340: http://bugs.squid-cache.org/show_bug.cgi?id=4340 > > > HTH, > > Alex. > P.S. I renamed get_sni_at_step1 to step1 in the above examples because > that ACL itself does not know anything about SNI and does not force > Squid to get SNI. _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
