Another possibility that has not been mentioned yet is that the sslproxy_* settings might be resulting in some form of server TLS error that causes the connection(s) to get stuck. On 16/12/2015 8:46 a.m., HackXBack wrote: > > sslproxy_version 0 "0" is an invalid setting for this directive. > sslproxy_options ALL ... tells Squid to actively use SSLv2 on the outbound server connection (because SSLv2-compatibility isone of 'all' the options enabled). With a whole lot of other hacks and features of SSL and TLS enabled - which make this proxy wide open to hijacking attacks ... POODLE, FREAK, all those types of thing. Any reasonably secure server would reject those connections on sight. The paranoid ones might even just DROP the packets rather than closing properly - which would result in what you describe without any further actions. Note that the connection to the client remains secure with the default library security minimums in place. So as far as the client can tell the end-to-end security is supposed to be MUCH higher (if only it was), green padlock, etc, etc. Whole bunch of lies now. > sslproxy_cert_error allow all After those vulnerabilities have been opened, this forces Squid to silently accept *any* type of errors that happen with the certificate exchange. Preventing Squid from reporting security attacks or other issues to either you or the client. So you have configured there is a proxy which openly permits the server or a middleware attacker between it and the server to do whatever they like. Silently and invisibly. Might as well be sending everything in plain-text over the open Internet. You are kind of lucky it dont work. Amos _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
