<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
<style type="text/css">body {min-height: 100px}
</style></head><body style=""><div><br>> On May 14, 2015 at 12:37 AM Amos Jeffries <squid3@treenet.co.nz> wrote:<br>> <br>> <br>> On 14/05/2015 10:47 a.m., Casey Daniels - mailinglist wrote:<br>> >> On May 13, 2015 at 3:25 AM Amos Jeffries <squid3@treenet.co.nz> wrote:<br>> >><br>> >><br>> >> On 13/05/2015 6:17 a.m., Casey Daniels wrote:<br>> >>> Hi,<br>> >>> I've been trying to figure out how to do some web filtering on HTTPs,<br>> >>> with no really good options given the layout I have. But then I just<br>> >>> happened to see this feature for Squid 3.5, and was wondering if I'm<br>> >>> understanding it correctly.<br>> >>><br>> >>> With the Peak and Splice feature, is it possible to run squid in a<br>> >>> transparent mode for SSL, and check for certain host and either deny the<br>> >>> connection all together or allow the connection without further<br>> >>> interference from Squid? Would this be completely transparent without<br>> >>> adding a trusted certificate from the proxy server to all user devices?<br>> >><br>> >> Depends on how you define "host" and what the TLS ClientHello<br>> >> information contains.<br>> >><br>> >> If you define "host" in the official standard Internet terminology (a<br>> >> single machine). Then no its not possible. NAT and "load balancing"<br>> >> utterly destroyed the ability to determine if the host being spoken to<br>> >> is the host indicated in the packets.<br>> >> Case in point is your interceptor - a completely different host to the<br>> >> one the client sees in its packets. Nothing stops other interceptors<br>> >> existing upstream from you.<br>> >><br>> >> If by "host" you actally meant FQDN or host *name*. It can be done when<br>> >> and only when the TLS SNI information is made available by the client.<br>> >><br>> >> Amos<br>> >><br>> > <br>> > Yes the second option, not the particular machine, but the FQDN<br>> > (i.e.<http://www.cooking.com> )<br>> <br>> <br>> # get TLS SNI details etc<br>> ssl_bump peek all<br>> <br>> # some get rejected<br>> acl blocked ssl:server_name .example.com<br>> ssl_bump reject blocked<br>> <br>> # the rest allowed without decrypting<br>> ssl_bump splice all<br>> <br>> <br>> > When is the TLS SNI information made available by the client? <br>> <br>> They send it or they dont. Nothign you or we can do about it.<br>> <br>> Amos<br>> _______________________________________________<br>> squid-users mailing list<br>> squid-users@lists.squid-cache.org<br>> http://lists.squid-cache.org/listinfo/squid-users</div>
<div> </div>
<div>Thank You,</div>
<div>Casey</div></body></html>