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_Haar@xxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
_______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users