[squid-users] ssl_bump peek in squid-3.5.3

[James Lay]

On Thu, 2015-04-23 at 17:18 +0930, Michael Hendrie wrote:

> 
> 
> > On 23 Apr 2015, at 4:28 pm, Michael Hendrie <michael at hendrie.id.au>
> > wrote:
> > 
> > 
> > 
> > 
> > 
> > > On 23 Apr 2015, at 4:21 pm, Amos Jeffries <squid3 at treenet.co.nz>
> > > wrote:
> > > 
> > > On 23/04/2015 6:29 p.m., Michael Hendrie wrote:
> > > 
> > > > Hi All
> > > > 
> > > > I’ve been running squid-3.4.x in tproxy mode with ssl_bump
> > > > server-first for some time and has been working great.
> > > > 
> > > > I have just moved to 3.5.3 to use peek to overcome some issues
> > > > with
> > > > sites that require SNI to serve up the correct certificate.  In
> > > > most
> > > > cases this is work well however I seem to have an issue that (so
> > > > far)
> > > > only effects the Safari web browser with certain sites.  As an
> > > > example, https://twitter.com <https://twitter.com/> and
> > > > https://www.openssl.org <https://www.openssl.org/> will result
> > > > in a
> > > > Safari error page “can’t establish a secure connection with the
> > > > server”.  There is also a correlating entry in the cache.log
> > > > 'Error
> > > > negotiating SSL connection on FD 45: error:140A1175:SSL
> > > > routines:SSL_BYTES_TO_CIPHER_LIST:inappropriate fallback (1/-1)’
> > > 
> > > 
> > > Please try the latest snapshot of 3.5 series. There are some TLS
> > > session
> > > resume and SNI bug fixes.
> > 
> > 
> > Thanks Amos, but I did try squid-3.5.3-20150420-r13802 before
> > posting….any other suggestions?
> > 
> > Michael
> 
> 
> 
> OK, I seem to have resolved this now, for the benefit of everyone else
> on the list:
> 
> 
> In the above tests the generated certificate was being signed by a
> RootCA that was installed as trusted in the browser certificate
> store.  
> 
> 
> I had previously noticed in my test environment (and thought
> completely unrelated) that bumped requests using the new peek/bump in
> 3.5.x were not sending the entire certificate chain to the browser but
> since they trusted the RootCA that was fine.  In my production
> environment however I use an IntermediateCA to sign the bumped
> requests, this causes a browser error as the clients only trust the
> RootCA.  As part of investigation to resolve this, I found that adding
> ‘cafile=/path/to/signing_ca_bundle’ to the ‘https_port' line (which in
> my config is exactly the same file as ‘cert=‘) that all certs are sent
> to the client, and I no longer face the issue with Safari and
> https://twitter.com or https://www.openssl.org regardless of using
> RootCA or InterCA to sign bumped requests.
> 
> 
> Not sure why but ‘ssl_bump server-first’ sends the entire chain
> without specifying ‘cafile=‘ and ‘ssl_bump peek/bump’ doesn’t…but
> anyway my problem is solved!
> 
> 
> Michael
> 
> 
> 
> _______________________________________________
> squid-users mailing list
> squid-users at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users


Michael,

Could you post your entire config here if possible?  Many of us continue
to face challenges with ssl_bump and a working config would be great.
Thank you.

James
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20150423/4cbe3ba7/attachment.html>