[squid-users] Skype Issues

Sat Jun 25 17:02:53 UTC 2016

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 <yvoinov at 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 at 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 at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20160625/8f89dc90/attachment.html>