Expressway Weak SSL/TLS Key Exchange Issue

[fdharmawan]

Hi Team,

Recently I got a report from my security team, stating that there is Weak SSL/TLS Key Exchange on our expressway deployment. The report is generated from Qualys. The result said this:

PROTOCOL NAME   GROUP                     KEY-SIZE   FORWARD-SECRET   CLASSICAL-STRENGTH   QUANTUM-STRENGTH
TLSv1.2                   ECDHE secp192r1   192            yes                             96                                   low

On the solution tab of the report, it is stated that:

Change the SSL/TLS server configuration to only allow strong key exchanges.

On Maintenance -> Security -> Ciphers, here are the entry on the ciphers:

EECDH:EDH:HIGH:-AES256+SHA:!MEDIUM:!LOW:!3DES:!MD5:!PSK:!eNULL:!aNULL

Here are the output when I issue xconfiguration // ciphers command:

xconfiguration // ciphers
*c xConfiguration Ciphers ForwardProxyTLSCiphers Value: "EECDH:EDH:HIGH:-AES256+SHA:!MEDIUM:!LOW:!3DES:!MD5:!PSK:!eNULL:!aNULL"
*c xConfiguration Ciphers ForwardProxyTLSProtocol Value: "minTLSv1.2"
*c xConfiguration Ciphers HTTPSCiphers Value: "EECDH:EDH:HIGH:-AES256+SHA:!MEDIUM:!LOW:!3DES:!MD5:!PSK:!eNULL:!aNULL"
*c xConfiguration Ciphers HTTPSProtocol Value: "minTLSv1.2"
*c xConfiguration Ciphers RemoteSyslog1TLSCiphers Value: "ALL"
*c xConfiguration Ciphers RemoteSyslog1TLSProtocol Value: "minTLSv1.0"
*c xConfiguration Ciphers RemoteSyslog2TLSCiphers Value: "ALL"
*c xConfiguration Ciphers RemoteSyslog2TLSProtocol Value: "minTLSv1.0"
*c xConfiguration Ciphers RemoteSyslog3TLSCiphers Value: "ALL"
*c xConfiguration Ciphers RemoteSyslog3TLSProtocol Value: "minTLSv1.0"
*c xConfiguration Ciphers RemoteSyslog4TLSCiphers Value: "ALL"
*c xConfiguration Ciphers RemoteSyslog4TLSProtocol Value: "minTLSv1.0"
*c xConfiguration Ciphers ReverseProxyTLSCiphers Value: "EECDH:EDH:HIGH:-AES256+SHA:!MEDIUM:!LOW:!3DES:!MD5:!PSK:!eNULL:!aNULL"
*c xConfiguration Ciphers ReverseProxyTLSProtocol Value: "minTLSv1.2"
*c xConfiguration Ciphers SIPTLSCiphers Value: "EECDH:EDH:HIGH:-AES256+SHA:!MEDIUM:!LOW:!3DES:!MD5:!PSK:!eNULL:+ADH"
*c xConfiguration Ciphers UcClientTLSCiphers Value: "EECDH:EDH:HIGH:-AES256+SHA:!MEDIUM:!LOW:!3DES:!MD5:!PSK:!eNULL:!aNULL"
*c xConfiguration Ciphers UcClientTLSProtocol Value: "minTLSv1.2"
*c xConfiguration Ciphers XCPTLSCiphers Value: "EECDH:EDH:HIGH:-AES256+SHA:!MEDIUM:!LOW:!3DES:!MD5:!PSK:!eNULL:!aNULL"
*c xConfiguration Ciphers XCPTLSProtocol Value: "minTLSv1.2"
*c xConfiguration Ciphers sshd_ciphers Value: "aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr,aes256-cbc,aes192-cbc,aes128-cbc"
*c xConfiguration Ciphers sshd_kex Value: "ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1"
*c xConfiguration Ciphers sshd_macs Value: "hmac-sha2-512,hmac-sha2-256,hmac-sha1"
*c xConfiguration Ciphers sshd_pfwd_ciphers Value: "aes256-ctr"
*c xConfiguration Ciphers sshd_pfwd_kexalgorithms Value: "ecdh-sha2-nistp384"
*c xConfiguration Ciphers sshd_pfwd_pubkeyalgorithms Value: "x509v3-sign-rsa"
*c xConfiguration Authentication ADS CipherSuite: "HIGH:MEDIUM:!ADH:!aNULL:!eNULL:-AES128-SHA256:@STRENGTH"

I am running 12.5.4 on the expressway. May I know how to resolve it? Thank you.

[felix3]

Well, if you are looking for feedback: be advised, X14.2 limits your TLS SIP connection options as they not only removed secp192r1 but also secp256r1 and secp521r1. Only secp384r1 stayed. This will cause negotiation failures if you try communicating with other systems that don't offer the 384 one. One example is the Zoomcloud SIP connector (zoomcrc.com). If your Enterprise makes B2B calls via SIP TLS with Zoom and doesn't allow for plain SIP fallback, you should not upgrade as those calls will all fail because of TLS negotiation failures. Even if not, if you plan on using 14.2.1 I recommend checking that all your important TLS partners can work with secp384r1 as escp curve.

CSCwd03647 describes the issue. Its already listed as fixed but there is no fixed version listed so I would assume its gonna be 14.2.2. I have tested 14.2.1. in my lab, the issue is definitely not fixed in that build. 

[MatthewEpps90485]

This is interesting.  I recently upgraded Expressways to x14.2.1 to resolve this Qualys scan issue.  When I did the first two clusters, I experienced significant tissues dialling zoomcrc.com - 40s-50s to connect and quite often endpoints would drop out of the meetings once they had connected. The Expressway logs were showing TLS negotiation errors. The following day, I was going to regress the upgrade and it suddenly everything was fine and has been since.

What is frustrating is that 2 out of 3 of my Expressway-E Clusters are still reporting the same Qualys scan issues. The Cipher suite configs are the same across all 3 clusters. About to raise a TAC case to investigate.,

[felix3]

I just tested this again and it looks like Zoom added the secp384r1 curve for kex which solves the issue of calling out to zoom on 14.2 and 14.2.1. 

As for the dial-in scenario (zoom calls expressway), someone would have to test that. I don't have a zoom instance to call out. Previously it wasn't possible (CSCwd55722) also due to TLS KEY errors. Even with the 14.2.2 alpha1 which previously fixed the dial-out by adding a bunch of new and modern other key methods.

As for the inconsistent behavior before, maybe it tried and failed at SIP TLS and fell back to unencrypted fallback alternatives which than failed due to other issues caused by using the fallback like other ports used or whatever.

[MatthewEpps90485]

I could only draw the conclusion that Zoom had changed something overnight when I did the upgrades and it looks like it may have been this addition of the secp384r1 curve for kex. Very coincidental that they may have done this on the Saturday night after my upgrades but a happy coincidence at that !!

With respect to the two clusters still failing then I've seen that the Diffie Hellman TLS key size is set to 1024 on the failing clusters but 2048 on the passing Cluster.  Why they are different is another mystery though - all Clusters were upgraded from and to the same versions.

[KacyHicks21882]

The compatibility matrix for CUCM 12.5.1 X recommends X14.0.6 for Expressways, until x14.2.2 is recommended what are we supposed use to secure this vulnerability?   

[MatthewEpps90485]

Hi Kacy,

X14.0.6 is the "recommended" version to match CUCM 12.5.1.x. However, that doesn't mean that newer versions aren't compatible. I have upgraded our Expressways to X14.2.1 and am running CUCM 12.5(1)SU3 and have experienced no issues.

If you do upgrade, there are some notes around certificates between CUCM & Expressways in the Release Notes for Expressway which need to be adhered to if you are using MRA so be mindful of those.

Bottom line, sometimes the need to have to upgrade to newer versions of Expressway, which are not listed as recommended in the CUCM compatibility tables, to resolve potentially serious security vulnerabilities outweighs always sticking to recommended versions.

Note that if you do upgrade your Expressways, you may hit this Bug - CSCwc88608. When I upgraded  my Expressway-C, the Zones to CUCM kept failing and it was due to this bug - simply manually adding "ECDHE-RSA-AES256-GCM-SHA384:" to the SIP TLS cipher suite, restarting the Expressways and the issue is resolved.