[squid-users] using splice just to improve TLS SNI logging

[Dan Charlesworth]

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 at trimble.com> 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 at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users