On 15/05/2015 11:15 a.m., Casey Daniels wrote: > > > On 05/14/2015 12:37 AM, Amos Jeffries wrote: >>> Yes the second option, not the particular machine, but the FQDN >>> (i.e.<http://www.cooking.com> ) >> >> # get TLS SNI details etc >> ssl_bump peek all >> >> # some get rejected >> acl blocked ssl:server_name .example.com >> ssl_bump reject blocked >> Sorry, I see now that should have been: ssl_bump terminate blocked >> # the rest allowed without decrypting >> ssl_bump splice all >> >> >>> When is the TLS SNI information made available by the client? >> They send it or they dont. Nothign you or we can do about it. >> > > One Follow up question. > > You said "They send it or they don't. Nothing you or we can do about > it." Are you referring to that we don't have control if they send it or > not, or there is nothing we can do if they don't? > Both. > My question is, is there some way to either reject the conection, or do > a full SSL bump the connection for further examnation if the TLS SNI > information isn't present? Have a read through the "actions" list in <http://wiki.squid-cache.org/Features/SslPeekAndSplice>. In the above config snippet the "peek" action will get the server FQDN from client SNI in intercepted traffic, or if it gets to step 2 the server name from the certificate. Write down in words the exact sequence of things you want Squid to do and usually that will be what the config options look like. > From my understanding all modern browsers > should be sending the TLS SNI information, and the SSL fallback has been > disabled by default on them except for Windows IE. So blocking > connections that fail to give TLS SNI information doesn't appear to be a > problem except for people using outdated devices. Or the over-50% of web traffic that is not sent by browsers. SNI is a relatively new feature and usage is growing, so YMWV. Amos _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
