Wasn't somebody saying that you'd need write an External ACL to evaluate the SNI host because dstdomain isn't hooked into that code (yet? ever?)?
On 27 January 2015 at 08:33, Jason Haar <jason_h...@trimble.com> wrote: > > Well the documentation says > > # SslBump1: After getting TCP-level and HTTP CONNECT info. > # SslBump2: After getting SSL Client Hello info. > # SslBump3: After getting SSL Server Hello info. > > > So that means SslBump1 only works for direct proxy (ie CONNECT) sessions, > it's SslBump2 that peeks into the traffic to discover the client SNI > hostname. So I think you actually need (I'll use more descriptive acl names > and comment out those that I think don't add any value) > > acl domains_nobump dstdomain "/etc/squid/domains_nobump.acl" > #no added value: acl DiscoverCONNECTHost at_step SslBump1 > acl DiscoverSNIHost at_step SslBump2 > #don't use - breaks bump: acl DiscoverServerHost at_step SslBump3 > #no added value - in fact forces peek for some reason: ssl_bump peek > DiscoverCONNECTHost all > ssl_bump peek DiscoverSNIHost all > > ssl_bump splice domains_nobump > #DiscoverSNIHost should now mean Squid knows about all the SNI details > ssl_bump bump all > > Sadly, this doesn't work for me *in transparent mode*. Works fine when > using squid as a formal proxy, but when used via https_port intercept, we > end up with IP address certs instead of SNI certs. > > We really need someone who knows more to tell us how to make this work :-( > > > -- > Cheers > > Jason Haar > Corporate Information Security Manager, Trimble Navigation Ltd. > Phone: +1 408 481 8171 > PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1 > > > _______________________________________________ > squid-users mailing list > squid-users@lists.squid-cache.org > http://lists.squid-cache.org/listinfo/squid-users > >
_______________________________________________ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
