<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Alex/Eliezer,</div><div class=""><br class=""></div><div class="">Thanks for you earlier comments and apologies for not responding (and saying thank you previously, squid got back-burnered unfortunately)</div><div class=""><br class=""></div><div class="">Getting logging working with transparent proxying was my initial step prior to looking at restricting specific sites via either ACLs or a URL rewriter (ufdbGuard, SquidGuard etc - although I don’t think SquidGuard works with SNI) </div><div class=""><br class=""></div><div class="">To reiterate, my desire is to have Squid running and capable of blocking access to http and https sites primarily based on the server name requested by the client (so no need to go beyond a peek)</div><div class="">For HTTP requests this is obviously out of the box stuff but for HTTPS it seems more complicated.</div><div class=""><br class=""></div><div class="">From everything I’ve read, it looks like the following ssl_bump lines should provide access to the SNI server name requested by the client. </div><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""></blockquote></blockquote></blockquote><span class="Apple-tab-span" style="white-space:pre"> </span>ssl_bump peek all<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>ssl_bump splice all<div class=""><br class=""></div><div class="">I can’t help thinking that I must have something wrong with my config:</div><div class="">- Log output correctly shows </div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>- SNI server name via ssl::>sni </div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>- Bump mode via ssl::bump_mode </div><div class="">- Implies my ssl_bump config is working</div><div class="">- Restricting access via a squid ACL doesn’t use the SNI server name for an HTTPS request </div><div class="">- Works fine for HTTP</div><div class=""><br class=""></div><div class="">Example ACL:</div><div class=""><div style="margin: 0px; font-size: 11px; font-family: Menlo;" class=""> acl blocked_sites ssl::server_name .<a href="http://apple.com" class="">apple.com</a></div></div><div class=""><div style="margin: 0px; font-size: 11px; font-family: Menlo;" class=""> http_access deny blocked_sites</div></div><div class=""><br class=""></div><div class="">Example access log output:</div><div class=""><div style="margin: 0px;" class=""><font face="Courier New" style="font-size: 11px;" class="">%ts.%03tu <span class="Apple-tab-span" style="white-space: pre;"> </span> %6tr %>a %Ss/%03>Hs <span class="Apple-tab-span" style="white-space: pre;"> </span> %<st %rm %ru %ssl::>sni </font><font face="Courier New" class=""><span style="font-size: 11px;" class="">%ssl::bump_mode </span></font><span style="font-size: 11px; font-family: 'Courier New';" class="">%[un %Sh/%<a %mt</span></div></div><div class=""><span style="font-family: 'Courier New';" class="">1485468402.401 575 10.1.0.1 TCP_TUNNEL/200 592 CONNECT 23.63.86.92:443 <a href="http://store.apple.com" class="">store.apple.com</a> peek - ORIGINAL_DST/23.63.86.92 -</span></div><div class=""><font face="Courier New" class="">1485469054.633 51 10.1.0.1 TCP_DENIED/403 3962 GET <a href="http://store.apple.com/" class="">http://store.apple.com/</a> - - - HIER_NONE/- text/html</font></div><div class=""><br class=""></div><div class="">Example cache log output:</div><div class="">2017/01/26 21:54:21.745 kid1| 28,5| <a href="http://Acl.cc" class="">Acl.cc</a>(138) matches: checking blocked_sites</div><div class=""><div class="">2017/01/26 21:54:21.745 kid1| 28,3| <a href="http://ServerName.cc" class="">ServerName.cc</a>(42) match: checking '23.63.86.92'</div><div class="">2017/01/26 21:54:21.745 kid1| 28,7| <a href="http://ServerName.cc" class="">ServerName.cc</a>(32) aclHostDomainCompare: Match:23.63.86.92 <> .<a href="http://apple.com" class="">apple.com</a></div><div class="">2017/01/26 21:54:21.745 kid1| 28,3| <a href="http://ServerName.cc" class="">ServerName.cc</a>(47) match: '23.63.86.92' NOT found</div><div class="">2017/01/26 21:54:21.745 kid1| 28,3| <a href="http://ServerName.cc" class="">ServerName.cc</a>(42) match: checking 'none'</div><div class="">2017/01/26 21:54:21.745 kid1| 28,7| <a href="http://ServerName.cc" class="">ServerName.cc</a>(32) aclHostDomainCompare: Match:none <> .<a href="http://apple.com" class="">apple.com</a></div><div class="">2017/01/26 21:54:21.745 kid1| 28,3| <a href="http://ServerName.cc" class="">ServerName.cc</a>(47) match: 'none' NOT found</div><div class="">2017/01/26 21:54:21.745 kid1| 28,3| <a href="http://Acl.cc" class="">Acl.cc</a>(158) matches: checked: blocked_sites = 0</div><div class="">2017/01/26 21:54:21.745 kid1| 28,3| <a href="http://Acl.cc" class="">Acl.cc</a>(158) matches: checked: http_access#5 = 0</div><div class="">2017/01/26 21:54:21.745 kid1| 28,5| <a href="http://Checklist.cc" class="">Checklist.cc</a>(400) bannedAction: Action 'ALLOWED/0is not banned</div></div><div class=""><br class=""></div><div class="">squid -v output:</div><div class=""><div class="">Squid Cache: Version 3.5.20</div><div class="">Service Name: squid</div><div class="">configure options: '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' '--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib64' '--libexecdir=/usr/libexec' '--sharedstatedir=/var/lib' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--disable-strict-error-checking' '--exec_prefix=/usr' '--libexecdir=/usr/lib64/squid' '--localstatedir=/var' '--datadir=/usr/share/squid' '--sysconfdir=/etc/squid' '--with-logdir=$(localstatedir)/log/squid' '--with-pidfile=$(localstatedir)/run/squid.pid' '--disable-dependency-tracking' '--enable-eui' '--enable-follow-x-forwarded-for' '--enable-auth' '--enable-auth-basic=DB,LDAP,MSNT-multi-domain,NCSA,NIS,PAM,POP3,RADIUS,SASL,SMB,SMB_LM,getpwnam' '--enable-auth-ntlm=smb_lm,fake' '--enable-auth-digest=file,LDAP,eDirectory' '--enable-auth-negotiate=kerberos' '--enable-external-acl-helpers=file_userip,LDAP_group,time_quota,session,unix_group,wbinfo_group' '--enable-cache-digests' '--enable-cachemgr-hostname=localhost' '--enable-delay-pools' '--enable-epoll' '--enable-ident-lookups' '--enable-linux-netfilter' '--enable-removal-policies=heap,lru' '--enable-snmp' '--enable-ssl-crtd' '--enable-storeio=aufs,diskd,ufs' '--enable-wccpv2' '--enable-esi' '--enable-ecap' '--with-aio' '--with-default-user=squid' '--with-dl' '--with-openssl' '--with-pthreads' '--disable-arch-native' '--disable-icap-client' 'build_alias=x86_64-redhat-linux-gnu' 'host_alias=x86_64-redhat-linux-gnu' 'CFLAGS=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -fpie' 'LDFLAGS=-Wl,-z,relro -pie -Wl,-z,relro -Wl,-z,now' 'CXXFLAGS=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -fpie' 'PKG_CONFIG_PATH=:/usr/lib64/pkgconfig:/usr/share/pkgconfig'</div></div><div class=""><br class=""></div><div class="">Is there anything obvious that I am missing as I’m a bit stumped now.</div><div class=""><br class=""></div><div class="">Thanks again</div><div class=""><br class=""></div><div class="">Mark</div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On 3 Jan 2017, at 23:35, Alex Rousskov <<a href="mailto:rousskov@measurement-factory.com" class="">rousskov@measurement-factory.com</a>> wrote:</div></blockquote><blockquote type="cite" class=""><br class="Apple-interchange-newline"></blockquote><blockquote type="cite" class=""><div class="">On 01/03/2017 04:11 PM, Mark Hoare wrote:<br class=""></div></blockquote><blockquote type="cite" class=""><br class=""></blockquote></div><div><blockquote type="cite" class=""><blockquote type="cite" class="">I think these are hangovers from earlier syntax (ssl_bump<br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class="">server-first all) which shouldn't be required under 3.5.</blockquote></blockquote><blockquote type="cite" class=""><br class=""></blockquote></div><div><blockquote type="cite" class="">Please note that the depricated server-first is a "bumping" (not</blockquote><blockquote type="cite" class="">splicing!) action, and you may see a lot more information in the<br class=""></blockquote><blockquote type="cite" class="">bumping-Squid logs, naturally.</blockquote><blockquote type="cite" class=""><br class=""></blockquote><blockquote type="cite" class="">Alex.</blockquote><blockquote type="cite" class=""><br class=""></blockquote><br class=""></div><div><blockquote type="cite" class=""><div class="">On 3 Jan 2017, at 23:10, Alex Rousskov <<a href="mailto:rousskov@measurement-factory.com" class="">rousskov@measurement-factory.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">On 01/03/2017 03:41 PM, Eliezer Croitoru wrote:<br class=""><br class=""><blockquote type="cite" class="">Squid in intercept or tproxy mode will know one thing about the tunnel\connection: IP+port.<br class=""></blockquote><br class="">... and SSL handshake information when peeking or staring at client/server.<br class=""><br class=""><br class=""><blockquote type="cite" class="">Since you are using:<br class=""><blockquote type="cite" class="">ssl_bump peek all<br class="">ssl_bump splice all<br class=""></blockquote></blockquote><br class=""><blockquote type="cite" class="">The connections will always be spliced and you will never see any<br class="">url.(are you expecting only the SNI or also the url?)<br class=""></blockquote><br class="">AFAICT, Mark is expecting Squid to log one of the server names, not the<br class="">HTTP request URL.<br class=""><br class=""><br class=""><blockquote type="cite" class="">I do not know but there might be a code that can report the SNI if exists in the logs.<br class=""></blockquote><br class="">According to squid.conf.documented, the following logformat %code is<br class="">supported in modern Squids:<br class=""><br class=""><blockquote type="cite" class="">ssl::>sni SSL client SNI sent to Squid. Available only<br class=""> after the peek, stare, or splice SSL bumping<br class=""> actions.<br class=""></blockquote><br class="">This %code is not in the default access.log line format, naturally.<br class=""><br class="">Squid can also analyze CN and other server certificate fields, but there<br class="">is no code to log them IIRC.<br class=""><br class=""><br class="">Please note that the intercepted server IP address, the client-supplied<br class="">SNI name, the server-supplied common name (CN), the server-supplied<br class="">alternative names, and the host info in the encrypted client HTTP<br class="">request, may all be different.<br class=""><br class="">Given the variety of information sources that might supply different<br class="">information, it is not clear to me whether %ru should be based on SNI<br class="">information when both TCP-level and SNI information is available. Or<br class="">should it be based on CN? Or perhaps on CN _unless_ SNI matches one of<br class="">the alternative names?? This is a complicated issue; even the smart<br class="">server_name ACL needs parameters to clarify what "server name(s)" the<br class="">admin really wants to use/trust...<br class=""><br class="">According to Mark's email, %ru uses TCP-level info. We could either<br class="">change %ru to use the "latest" info (like the server_name ACL does) or<br class="">add a new logformat code that does that while leaving the old %ru and<br class="">friends alone. Given the complexity of the issue, the latter may be a<br class="">better approach.<br class=""><br class=""><br class="">HTH,<br class=""><br class="">Alex.<br class=""><br class=""><blockquote type="cite" class="">-----Original Message-----<br class="">From: squid-users [<a href="mailto:squid-users-bounces@lists.squid-cache.org" class="">mailto:squid-users-bounces@lists.squid-cache.org</a>] On Behalf Of Mark Hoare<br class="">Sent: Saturday, December 31, 2016 4:38 PM<br class="">To: <a href="mailto:squid-users@lists.squid-cache.org" class="">squid-users@lists.squid-cache.org</a><br class="">Subject: [squid-users] ssl_bump - peek & splice logging IP rather than server name<br class=""></blockquote><br class=""><blockquote type="cite" class="">Extract from access log:<br class=""><blockquote type="cite" class="">1483193882.790 870 <local ip removed> TCP_TUNNEL/200 5620 CONNECT 64.41.200.100:443 - ORIGINAL_DST/64.41.200.100 -<br class=""></blockquote></blockquote><br class=""><blockquote type="cite" class="">From the output above I would have expected some of the server name info to get into the access log.<br class=""></blockquote><br class=""><blockquote type="cite" class=""><blockquote type="cite" class="">http_port 3128<br class=""><br class="">https_port 3130 intercept ssl-bump cert=/etc/squid/ssl_cert/squidCA.pem generate-host-certificates=on dynamic_cert_mem_cache_size=4MB<br class=""><br class="">http_port 3131 intercept ssl-bump cert=/etc/squid/ssl_cert/squidCA.pem generate-host-certificates=on dynamic_cert_mem_cache_size=4MB<br class=""></blockquote></blockquote><br class=""><blockquote type="cite" class=""><blockquote type="cite" class="">ssl_bump peek all<br class="">ssl_bump splice all<br class=""></blockquote></blockquote><br class=""></div></blockquote></div><br class=""></body></html>