On 2/02/2016 12:55 a.m., Tom Tom wrote: > Hi list > Using Squid 3.5.11 and playing with Peek-and-splice and > SSL-Fingerprinting. I've configured the following settings: > > acl SSL_BLACKLIST server_cert_fingerprint "/etc/squid/SSL_BLACKLIST" > acl DENY_SSL_BUMP ssl::server_name_regex -i "/etc/squid/DENY_SSL_BUMP" > acl step1 at_step SslBump1 > acl step2 at_step SslBump2 > acl step3 at_step SslBump3 > > ssl_bump splice DENY_SSL_BUMP > ssl_bump stare all > ssl_bump terminate SSL_BLACKLIST > ssl_bump bump all > > With this config, connections with known fingerprints are terminated > and sites, which shouldn't be bumped, are spliced. > > It's working fine, but for me it's suspicious, why I don't need to > define a "at_step"-directive. Does the word "all" within the > "stare"-directive means all-steps? Or refers the "all" to the implied > ACL "all"-directive? It means any traffic which arrived from a client with an IP address. In otherwords it always matches at any step where "stare" is a valid action. If the splice is not triggered immediately by a CONNECT hostname, the "stare all" is causing the clientHello to befetched which again might cause splice at step2 to happen based on the SNI. Otherwise the step2 "stare all" fetches the serverHellow data. At that point it is unclear whether the splice would happen based on server cert Subject matching the server_name_regex. But probably it is prevented by: "Staring at the server certificate usually precludes future splicing of the connection.", so the bump or terminate happens instead. > When replacing "ssl_bump stare all" with "ssl_bump stare step1", then > terminating the connection while catching a known ssl-fingerprint > isn't working. Why? step1 is about clientHello data. AFAIK, "SSL fingerprint" is about the X.509 certificate in the serverHello at step2. Amos _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
