[squid-users] ssl_bump peek in squid-3.5.3

Michael Hendrie michael at hendrie.id.au
Thu Apr 23 07:48:25 UTC 2015


> 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 <https://twitter.com/> or https://www.openssl.org <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

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


More information about the squid-users mailing list