[squid-users] Possible SSL Bug in v3.5.13?

Wed Jan 13 04:28:37 UTC 2016

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