On 26/06/2016 1:19 a.m., Renato Jop wrote: > Hello, > I've configured squid to filter both HTTP and HTTPS traffic and for the > most part the squid server is working correctly, however, I am always > unable to login with skype. Skype does send all the requests through the > suid server, but looking into the cache.log I always get a Error > negotiating SSL connection on FD 12: error:1408A0C1:SSL > routines:SSL3_GET_CLIENT_HELLO:no shared cipher. > If I run: openssl s_client -crlf -connect 157.55.56.164:443 I get exactly > the same error. However if I run: openssl s_client -crlf -connect > 157.55.56.164:443 -tls1_2 -ssl2 I am able to connect. > If I disable HTTPS, skype logins with no problems. > I've searched on the mailing list archive and found that other people have > had the same issues but none have been able to fix them. Is this a known > issue with squid? Any help would be greatly appreciated. Yes its known. Well two problems are known with Skype... 1) Handling Skype cleanly through Squid with HTTPS interception (aka SSL-Bump) currently requires features from Squid-4. Specifically the on_unsupported_protocol feature to avoid having to bypass each IP address your clients connect to manually (PITA) for the connections at least some versions of it make that dont use TLS/SSL on port 443. This does not seem to be your particular problem though. Maybe you will hit it only after solving the "no shared cipher" problem. 2) Recently a few people have been finding the "no shared cipher" issue appearing with other software or domains. Last sighting of it turned out to be the new ChaCha and Poly1305 ciphers. Which required a migration to LibreSSL since OpenSSL implementation was still finding bugs as recently as March this year. But wait, theres more ... > http_port 175.15.2.239:8080 ssl-bump generate-host-certificates=on > dynamic_cert_mem_cache_size=100MB cert=/usr/local/etc/squid/serverkey.pem > capath=/usr/local/share/certs/ > 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 > dhparams=/etc/dh-parameters.2048 options=NO_SSLv2,NO_SSLv3,SINGLE_DH_USE > > http_port 127.0.0.1:8080 intercept ssl-bump generate-host-certificates=on > dynamic_cert_mem_cache_size=100MB cert=/usr/local/etc/squid/serverkey.pem > capath=/usr/local/share/certs/ > 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 > dhparams=/etc/dh-parameters.2048 options=NO_SSLv2,NO_SSLv3,SINGLE_DH_USE > > https_port 127.0.0.1:3129 intercept ssl-bump generate-host-certificates=on > dynamic_cert_mem_cache_size=100MB cert=/usr/local/etc/squid/serverkey.pem > capath=/usr/local/share/certs/ > 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 > dhparams=/etc/dh-parameters.2048 options=NO_SSLv2,NO_SSLv3,SINGLE_DH_USE > It is easy to think that the above enables a lot of ciphers. HOWEVER, most of them involve "EC" and that requires a curve to be configured as well. You are using the dhparams= option instead of tls-dh= option. Thus have not told Squid what Curve to use for any EC. So most of those "allowed" ciphers are thus not working. Which means you effectively have configured only this: cipher=EDH+aRSA:HIGH:!RC4:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS I'm not sure right now how many ciphers "HIGH" enables with those following rejections, but I'd bet its also not many. That limited number of ciphers on your side of the TLS handshake may be at least a big part of what is leading to "no shared cipher" situation. You have a few things that might help there. In the order you should try them: * Using the tls-dh= option with a curve name. It might start working with an EC cipher. * Using an updated library with ChaCha and Poly1305 ciphers. In case the other end only wants one of those. This should not require a rebuild of Squid, but it might. * An upgrade to Squid-4. > sslproxy_capath /usr/local/share/certs/ > sslproxy_options NO_SSLv2,NO_SSLv3,SINGLE_DH_USE > 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 Note: The outgoing connections might actually do the Elliptic Curves. Since the server tells Squid what curve to use. > sslproxy_cert_error allow all Nasty. Anyone is allowed to hack your proxies outgoing connections and do what they like to the TLS. You will ignore any security alerts or errors TLS/SSL protocol uses to protect you. So, whats the point of extending the acceptable CA with sslproxy_capath if you are going to ignore the verification results? Whats the point of TLS if anyone is allowed to break into the "secure" connections? Amos _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
