Thanks both for you help. I'll try to make this changes and see if this solves my issues.
Renato Jop On Sat, Jun 25, 2016 at 10:32 AM, Yuri Voinov <yvoi...@gmail.com> wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Amos, you are a wrong. > > No Squid-4. It's unstable and not ready for production. Whenever it's > features. > > Some time ago I have the same issue and know what happens exactly. > > Skype initial connection site uses RC4 cipher. Which is disabled in most > squid's configuration. > > To make it works (as by as most M$ update sites) it's require simple use > this cipher's suite: > > HIGH:MEDIUM:RC4:3DES:!aNULL:!eNULL:!LOW:!MD5:!EXP:!PSK:!SRP:!DSS > > That works for me in 5 SSL bumped setups. There is no matter which squid > version installed. > > > 25.06.2016 20:22, Amos Jeffries пишет: > > 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@lists.squid-cache.org > > http://lists.squid-cache.org/listinfo/squid-users > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iQEcBAEBCAAGBQJXbrIRAAoJENNXIZxhPexGirEH/AzlKxZRG7dBgzHTrFNwAJdS > kO4Q1a18TsFRQLgC7nYuA2BQVVY7ORBDFYJ0z++Jb+wWFqqXYCWBrfeH0XSjPCoQ > uTMJoKRBzIqb5ZXGs5/GlRvRvWBW2Q8wOPk9Ig4fPVJS9fMulXyaukemD+h8Nu1/ > UUzoZKtEQxH6ICLVgkJWrQSWvJNWzOSQ6vS9GZYxW4Pu7qnjNiXhx+mDN+ZUH6tf > rCMKqBSIOOL1axf7Gt6wUn9ctu2Y9d/avYim5rsqRbJ4Th4P31QWhw3DOXKW/vDw > avhXgThQgq2PsHcijeSZEccJUdD4vNlgPWJIxVDkjj6Ypy8TX+4fChpnMlXKa3Y= > =Gvwa > -----END PGP SIGNATURE----- > > > _______________________________________________ > squid-users mailing list > squid-users@lists.squid-cache.org > http://lists.squid-cache.org/listinfo/squid-users > >
_______________________________________________ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
