[squid-users] Skype Issues

Sat Jun 25 16:32:18 UTC 2016

-----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-----

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x613DEC46.asc
Type: application/pgp-keys
Size: 2437 bytes
Desc: not available
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20160625/77e1535a/attachment.key>