[squid-users] Skype Issues

[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