Hi Together, first of all - thanks to Alex for the fast answer! > You may have misinterpreted what that bug report says. The reporter > placed his selfCA into the browser. The reporter did not use a CA > certificate from a well-known CA root in his signing chain -- it is not > possible to do that because you do not have the private key from that > well-known root CA certificate. Admit I got the bug report wrong then. However I need a solution where the client configuration is not changed (no additional CA, no proxy setup in the Browser) yesterday I came accross ssl-bump peek-and-splice which looks really promising as it reports the ServerName: 2013/04/25 14:51:20.856| bio.cc(674) parseV3Hello: SSL Exntension: 0 of size:f 2013/04/25 14:51:20.856| bio.cc(682) parseV3Hello: Found server name: google.com 2013/04/25 14:51:20.856| bio.cc(674) parseV3Hello: SSL Exntension: a of size:8 This would be enough for me to decide if I bump the request or not, unfortunately I fail to write an ACL catching the ServerName in the Hello, went through squid.conf.documented and http://wiki.squid-cache.org/Features/SslPeekAndSplice and found a example here: http://www.squid-cache.org/mail-archive/squid-dev/201302/0013.html but all I could tell is to start with: ssl_bump peek-and-splice [acl] so what should be in the acl? and how to check for the 'parseV3Hello ServerName' value? I know this feature is still under development, so is this possible or did I get something wrong again? Any comment/links or further documentation would be welcome. and not to forget: filtering for dst IP is, like changing the configuration for the client, out of scope in times of DNS loadbalancing and the usage of CDNs. Thanks in advance, Alex
