On 01/26/2017 03:38 PM, Mark Hoare wrote: > 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) ... or even beyond a peek at the client. > 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. > ssl_bump peek all > ssl_bump splice all Yes, but you are also telling Squid to peek at the server certificate. If you want to avoid doing that, then replace "peek all" with "peek step1" while providing the right step1 ACL. The SNI-based denial you want should happen earlier anyway, but if you do peek at the server certificate, then you may also deny later, based on server-supplied information (e.g., when SNI was missing or was not matching). Whether more denials based on server info is a good thing is your decision. > I can’t help thinking that I must have something wrong with my config: > - Log output correctly shows > - SNI server name via ssl::>sni > - Bump mode via ssl::bump_mode > - Implies my ssl_bump config is working > - Works fine for HTTP Great! > - Restricting access via a squid ACL doesn’t use the SNI server name for > an HTTPS request You may be right, but not for the reasons you think. The output you have shown does not necessarily confirm any problems. > Example ACL: > acl blocked_sites ssl::server_name .apple.com > http_access deny blocked_sites Please note that your Squid version is missing a critical ssl::server_name fix detailed below. > Example access log output: > %ts.%03tu %6tr %>a %Ss/%03>Hs %<st %rm %ru > %ssl::>sni %ssl::bump_mode %[un %Sh/%<a %mt > 1485468402.401 575 10.1.0.1 TCP_TUNNEL/200 592 CONNECT 23.63.86.92:443 > store.apple.com peek - ORIGINAL_DST/23.63.86.92 - > 1485469054.633 51 10.1.0.1 TCP_DENIED/403 3962 GET http://store.apple.com/ > - - - HIER_NONE/- text/html The above shows that Squid peeked and denied access. To serve the error page to the client, Squid bumped the client connection first and then denied the first encrypted HTTP request. This is normal/expected. > Example cache log output: > 2017/01/26 21:54:21.745 kid1| 28,5| Acl.cc(138) matches: checking blocked_sites > 2017/01/26 21:54:21.745 kid1| 28,3| ServerName.cc(42) match: checking '23.63.86.92' > 2017/01/26 21:54:21.745 kid1| 28,7| ServerName.cc(32) aclHostDomainCompare: Match:23.63.86.92 <> .apple.com > 2017/01/26 21:54:21.745 kid1| 28,3| ServerName.cc(47) match: '23.63.86.92' NOT found > 2017/01/26 21:54:21.745 kid1| 28,3| ServerName.cc(42) match: checking 'none' > 2017/01/26 21:54:21.745 kid1| 28,7| ServerName.cc(32) aclHostDomainCompare: Match:none <> .apple.com > 2017/01/26 21:54:21.745 kid1| 28,3| ServerName.cc(47) match: 'none' NOT found > 2017/01/26 21:54:21.745 kid1| 28,5| Checklist.cc(400) bannedAction: Action 'ALLOWED/0is not banned If the above was for step1 checks, then it makes sense: The access was not banned based on TCP level information. Proceed to step2 (extract SNI and test again). There should be more checks like the above, and then Squid decided to deny access. However, the timing of that decision and the sources of information used for that decision may change after the ssl::server_name fix mentioned below. > Squid Cache: Version 3.5.20 You are missing the following server_name fix (among other things): > revno: 14110 > branch nick: 3.5 > timestamp: Mon 2016-11-14 23:51:24 +1300 > message: > Fix ssl::server_name ACL badly broken since inception. > > The original server_name code mishandled all SNI checks and some rare > host checks: > > * The SNI-derived value was pointing to an already freed memory storage. > * Missing host-derived values were not detected (host() is never nil). > * Mismatches were re-checked with an undocumented "none" value > instead of being treated as mismatches. > > Same for ssl::server_name_regex. > > Also set SNI for more server-first and client-first transactions. > > This is a Measurement Factory project. The first rule of SslBumping: Use the latest code. HTH, Alex. P.S. Please avoid HTMLifying your emails, especially when quoting logs. >> On 3 Jan 2017, at 23:35, Alex Rousskov wrote: >> >> On 01/03/2017 04:11 PM, Mark Hoare wrote: >> >>> I think these are hangovers from earlier syntax (ssl_bump >>> server-first all) which shouldn't be required under 3.5. >> >> Please note that the depricated server-first is a "bumping" (not >> splicing!) action, and you may see a lot more information in the >> bumping-Squid logs, naturally. >> >> Alex. >> > >> On 3 Jan 2017, at 23:10, Alex Rousskov >> <rousskov@xxxxxxxxxxxxxxxxxxxxxxx >> <mailto:rousskov@xxxxxxxxxxxxxxxxxxxxxxx>> wrote: >> >> On 01/03/2017 03:41 PM, Eliezer Croitoru wrote: >> >>> Squid in intercept or tproxy mode will know one thing about the >>> tunnel\connection: IP+port. >> >> ... and SSL handshake information when peeking or staring at >> client/server. >> >> >>> Since you are using: >>>> ssl_bump peek all >>>> ssl_bump splice all >> >>> The connections will always be spliced and you will never see any >>> url.(are you expecting only the SNI or also the url?) >> >> AFAICT, Mark is expecting Squid to log one of the server names, not the >> HTTP request URL. >> >> >>> I do not know but there might be a code that can report the SNI if >>> exists in the logs. >> >> According to squid.conf.documented, the following logformat %code is >> supported in modern Squids: >> >>> ssl::>sni SSL client SNI sent to Squid. Available only >>> after the peek, stare, or splice SSL bumping >>> actions. >> >> This %code is not in the default access.log line format, naturally. >> >> Squid can also analyze CN and other server certificate fields, but there >> is no code to log them IIRC. >> >> >> Please note that the intercepted server IP address, the client-supplied >> SNI name, the server-supplied common name (CN), the server-supplied >> alternative names, and the host info in the encrypted client HTTP >> request, may all be different. >> >> Given the variety of information sources that might supply different >> information, it is not clear to me whether %ru should be based on SNI >> information when both TCP-level and SNI information is available. Or >> should it be based on CN? Or perhaps on CN _unless_ SNI matches one of >> the alternative names?? This is a complicated issue; even the smart >> server_name ACL needs parameters to clarify what "server name(s)" the >> admin really wants to use/trust... >> >> According to Mark's email, %ru uses TCP-level info. We could either >> change %ru to use the "latest" info (like the server_name ACL does) or >> add a new logformat code that does that while leaving the old %ru and >> friends alone. Given the complexity of the issue, the latter may be a >> better approach. >> >> >> HTH, >> >> Alex. >> >>> -----Original Message----- >>> From: squid-users [mailto:squid-users-bounces@xxxxxxxxxxxxxxxxxxxxx] >>> On Behalf Of Mark Hoare >>> Sent: Saturday, December 31, 2016 4:38 PM >>> To: squid-users@xxxxxxxxxxxxxxxxxxxxx >>> <mailto:squid-users@xxxxxxxxxxxxxxxxxxxxx> >>> Subject: ssl_bump - peek & splice logging IP rather >>> than server name >> >>> Extract from access log: >>>> 1483193882.790 870 <local ip removed> TCP_TUNNEL/200 5620 CONNECT >>>> 64.41.200.100:443 - ORIGINAL_DST/64.41.200.100 - >> >>> From the output above I would have expected some of the server name >>> info to get into the access log. >> >>>> http_port 3128 >>>> >>>> https_port 3130 intercept ssl-bump >>>> cert=/etc/squid/ssl_cert/squidCA.pem generate-host-certificates=on >>>> dynamic_cert_mem_cache_size=4MB >>>> >>>> http_port 3131 intercept ssl-bump >>>> cert=/etc/squid/ssl_cert/squidCA.pem generate-host-certificates=on >>>> dynamic_cert_mem_cache_size=4MB >> >>>> ssl_bump peek all >>>> ssl_bump splice all >> > _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
