It’s been a far superior client experience to bumping on the deployments I’ve seen. Obviously MITM-ing a connection is always going to be a less amenable situation for clients; technically and ethically. The only problem I’ve had with splicing is this Host Header Forgery error squid has when it resolves a different IP for an HTTPS host than the client does. It’s pretty well minimised by making sure the client and squid box are using the same DNS server, but I still have the occasional timeouts on github.com and missing images/media on twitter.com because of it. > On 4 Dec 2015, at 2:35 PM, Jason Haar <Jason_Haar@xxxxxxxxxxx> wrote: > > Hi there > > We just had an incident where I would really have liked to have had > transparent TLS intercept in place. Currently I'm still in > "experimental" phase and don't want to go full "bump", but some quick > testing of just activating "splice" with TLS intercept seems to me to be > zero risk > > ie instead of allowing direct port 443 Internet access, redirect it back > onto squid-3.5 set to splice all port 443 traffic. End result is squid > logfiles containing the following > > .. CONNECT 1.2.3.4:443 blah > .. CONNECT real.SNI.name:443 blah > > Then at least I can see what HTTPS sites have been visited when I need to. > > Does going "splice" mode avoid all the potential SSL/TLS issues > surrounding bump? ie it won't care about client certs, weird TLS > extensions, etc? (ie other than availability, it shouldn't introduce a > new way of failing?) > > Thanks! > > -- > 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
