[squid-users] using splice just to improve TLS SNI logging
dan at getbusi.com
Fri Dec 4 03:47:46 UTC 2015
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 188.8.131.52: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?)
> 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
More information about the squid-users