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

Amos Jeffries squid3 at treenet.co.nz
Thu Jan 14 15:10:21 UTC 2016


On 15/01/2016 3:47 a.m., David Marcos wrote:
> Eliezer, Amos,
> 
> I wanted to follow-up on the below thread since I encountered an
> additional, interesting issue.
> 
> Per my issue with shutterfly.com below, if I *do not* set an ECDH cipher in
> the tls-dh parameter, then I have to remove NO_SSLv2 from sslproxy_options.
> 
> However, if I set an ECDH cipher (I chose secp384r1), I can add NO_SSLv2
> back to sslproxy_options and shutterfly.com works without a hitch.  My full
> sslproxy_options list now looks as follows having set the ECDH cipher in
> tls-dh -
> 
> sslproxy_options
> No_Compression,NO_TLSv1,NO_SSLv2,NO_SSLv3,SINGLE_ECDH_USE,SINGLE_DH_USE,CIPHER_SERVER_PREFERENCE
> 
> I don't know if this is a bug or expected behavior, so defer to you.  If
> you'd like me to submit a bug request, I can do so.

That negotiation behaviour is within the expected range of things. It is
possible the server has disabled the old DH ciphers unless SSLv2 is
negotiated. Combined with your previous config that would result in
Squid not being able to negotiate any cipher at all with TLSv1.1+ protocols.

The event should not be affecting any other traffic through the proxy
though. So if it really is crashing or hanging Squid that is a bug.

Amos



More information about the squid-users mailing list