On 13/01/2016 3:42 p.m., David Marcos wrote: > I recently upgraded to Squid v3.5.13 and am encountering at least two > errors when processing certain HTTPS connections. I am not sure if it is a > bug or a configuration error on my part. > > The first error I am seeing is when shutterfly.com is accessed by a user. > The issue occurs regardless of whether I splice or bump the site. A user > can browse to the page, but if they click on anything on the site, squid > encounters a fault. The system does not crash; it recovers, but the proxy > is down for about 30 seconds. Note that this occurs in regular forward > proxy mode, not intercept mode. Squid crashing or hanging entirely is very odd. Especially with splice, which is just blindly passing the TLS details between client and server. > > My knowledge of SSL is somewhat limited, so I am not sure if I have > misconfigured things in a way that creates the problem. Two questions I > have are (a) to apply ECDH properly, must an optional cipher be chosen for > the tls-dh option? and (b) to properly apply ECDH, do I have to recreate > the dhparam file using an ECDH cipher (I'm currently using the dhparam file > that I previously had)? If you omit or misconfigure the tls-dh / dhparams in a way that is not complained about on startup/reconfigure all that happens is the DH based ciphers are not usable. The RSA, DES, AES etc ciphers should all still work normally. When dhparam= or tls-dh= is configured "old-style" (ie with no curve name) it only sets the parameters necessary for plain DH or EDH/DHE ciphers to be used. When tls-dh= is set with a curve name then the ECDH and EECDH/ECHDE ciphers are configured. > > Separate from the above (or perhaps related), the second issue I am also > seeing are odd errors in the cache.log that are causing squid to fault and > recover. I am not yet sure which sites are causing the issue, but I am > seeing the following error: FATAL: dying from an unhandled exception: > !theConsumer. This error seems to be consistently preceded by "Error > negotiating SSL on FD 25: error:14077102:SSL > routines:SSL23_GET_SERVER_HELLO:unsupported protocol (1/-1/0)". This is usually seen when non-TLS protocol (ie plain HTTP) is being received in the HTTPS port. Or in recent releases it could possibly be SSLv2 or SSLv2-compatible protocol being received by a library that does not support SSLv2 on a SSLv3+ or TLSv1+ -only port. > > The prior version I was running was v3.5.12 and I know that version had no > problems when accessing shutterfly.com nor the odd FATAL message I am > seeing with the below configuration. > > Following is more detailed info for the first problem I am encountering > above with shutterfly.com. Please let me know additional information is > needed. > > Cache.log extracts when accessing shutterfly.com: > -------------------------------------------------------------------- > > 2016/01/12 22:39:59 kid1| Error negotiating SSL on FD 91: > error:14077102:SSL routines:SSL23_GET_SERVER_HELLO:unsupported protocol > (1/-1/0) > > 2016/01/12 22:39:59 kid1| Error negotiating SSL on FD 98: > error:14077102:SSL routines:SSL23_GET_SERVER_HELLO:unsupported protocol > (1/-1/0) > > 2016/01/12 22:39:59 kid1| Error negotiating SSL on FD 89: > error:14077102:SSL routines:SSL23_GET_SERVER_HELLO:unsupported protocol > (1/-1/0) > > 2016/01/12 22:40:02 kid1| Error negotiating SSL on FD 62: > error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify > failed (1/-1/0) > > 2016/01/12 22:40:02 kid1| Error negotiating SSL on FD 63: > error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify > failed (1/-1/0) > > 2016/01/12 22:40:03 kid1| Error negotiating SSL on FD 56: > error:14077102:SSL routines:SSL23_GET_SERVER_HELLO:unsupported protocol > (1/-1/0) > > 2016/01/12 22:40:03 kid1| Error negotiating SSL on FD 56: > error:14077102:SSL routines:SSL23_GET_SERVER_HELLO:unsupported protocol > (1/-1/0) > 2016/01/12 22:40:03 kid1| Error negotiating SSL on FD 58: > error:14077102:SSL routines:SSL23_GET_SERVER_HELLO:unsupported protocol > (1/-1/0) > > > Extracts from my squid.conf file: > ---------------------------------------------- > > http_port 127.0.0.1:3128 > > http_port 192.168.10.1:3128 ssl-bump generate-host-certificates=on > dynamic_cert_mem_cache_size=4MB cert=cert.pem tls-dh=cert.dhparam.pem > > http_port 192.168.10.1:3129 intercept disable-pmtu-discovery=transparent > name=http_icept > > https_port 192.168.10.1:3130 intercept disable-pmtu-discovery=transparent > ssl-bump generate-host-certificates=on dynamic_cert_mem_cache_size=4MB > cert=cert.pem tls-dh=cert.dhparam.pem name=https_icept > > sslcrtd_program /usr/lib/squid/ssl_crtd -s /disk/dyn-certs/sslcrtd_db -M 4MB > > ... > > ssl_bump peek SSL_Step1 !dont_peek_or_stare mynet > > ssl_bump splice dont_bump_me mynet > > ssl_bump bump mynet > > ssl_bump terminate all > Since the above rules all contain "mynet" as a criterion for happening, why not you re-order as: ssl_bump terminate !mynet ssl_bump peek SSL_Step1 !dont_peek_or_stare ssl_bump splice dont_bump_me ssl_bump bump all > > sslproxy_foreign_intermediate_certs /etc/ssl/certs/ > This new directive takes a filename. Not a directory name. > sslproxy_options > No_Compression,NO_TLSv1,NO_SSLv2,NO_SSLv3,SINGLE_DH_USE,CIPHER_SERVER_PREFERENCE > > sslproxy_cipher > EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH+aRSA+RC4:EECDH:EDH+aRSA:HIGH:!RC4:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS > The tls-dh / dhparams settings lacking a curve name for the EC* or EEC* part mean that these ciphers will not work despite being configured as acceptible : EECDH+ECDSA+AESGCM: EECDH+aRSA+AESGCM: EECDH+ECDSA+SHA384: EECDH+ECDSA+SHA256: EECDH+aRSA+SHA384: EECDH+aRSA+SHA256: EECDH+aRSA+RC4:EECDH: Leaving your proxy only able to use this one: EDH+aRSA Amos _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
