We do not use cache-peer. I thought cache-peer is for connecting another squid-like proxy server.
Without ssl-bump, the connection is tunneled transparently, so there is no chance to redirect each HTTP requests proxied under SSL connection. We want to redirec each HTTP requests under SSL, so we have to use ssl-bump to terminate the connection, and squid open another connection to the server we use content redirect to specify. The code take effect when the squid opens the new connection to each designed server for each HTTPS requests. We terminated CONNECT call at squid also to ensure we can intercept HTTP requests at squid, Alex > To: squid-users@lists.squid-cache.org > From: squ...@treenet.co.nz > Date: Thu, 23 Jul 2015 00:21:31 +1200 > Subject: Re: [squid-users] SSL connction failed due to SNI after content > redirection > > On 22/07/2015 12:44 p.m., Alex Wu wrote: > > it depends on how you set up squid, and where the connection is broken. The > > patch addessed the issue that occured using sslbump and content redirect > > together. > > > > I'd like some clarification what the exact problem symptoms are please. > > AFAIK, both redirect and re-write actions happen a relatively long time > *after* the bumping TLS handshakes to server are completed. Its far too > late to send the pre-handshake SNI data to the server. > > I can see this change as affecting reverse-proxy / CDN configurations > with TLS on both connections. But you said this was SSL-bumping, and > reverse-proxy configurations already have a cache_peer option to set the > internal domain name without re-write/redirect. > > Amos > > _______________________________________________ > 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
