Re: [squid-users] ssl_bump peek in squid-3.5.3
On 23 Apr 2015, at 9:22 pm, James Lay j...@slave-tothe-box.net wrote: 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 My ssl_bump configuration is contained in a separate conf file that is “included” via the main squid.conf file. There is nothing special about my main squid.conf, here is the contents of the include: https_port 8090 tproxy ssl-bump generate-host-certificates=on dynamic_cert_mem_cache_size=16MB cert=/etc/squid/ssl-bump.cer key=/etc/squid/ssl-bump.key cafile=/etc/squid/ssl-bump.cer acl p8090 myportname 8090 acl step1 at_step SslBump1 ssl_bump peek step1 ssl_bump bump p8090 Which was built using information from http://wiki.squid-cache.org/Features/SslPeekAndSplice http://wiki.squid-cache.org/Features/SslPeekAndSplice ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] ssl_bump peek in squid-3.5.3
On 23 Apr 2015, at 4:21 pm, Amos Jeffries squ...@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 ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] ssl_bump peek in squid-3.5.3
On 23 Apr 2015, at 4:28 pm, Michael Hendrie mich...@hendrie.id.au wrote: On 23 Apr 2015, at 4:21 pm, Amos Jeffries squ...@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 ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] ssl_bump peek in squid-3.5.3
On Thu, 2015-04-23 at 17:18 +0930, Michael Hendrie wrote: On 23 Apr 2015, at 4:28 pm, Michael Hendrie mich...@hendrie.id.au wrote: On 23 Apr 2015, at 4:21 pm, Amos Jeffries squ...@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@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 ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
