Search squid archive

Re: Possible SSL Bug in v3.5.13?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users




[Index of Archives]     [Linux Audio Users]     [Samba]     [Big List of Linux Books]     [Linux USB]     [Yosemite News]

  Powered by Linux