topic Did you reboot your JG server in Collaboration Applications

Jabber Guest doesn't work with Expressway 8.7.2

WolSen000 — Mon, 18 Mar 2019 01:01:20 GMT

Hi,

the latest Expressway requires Diffie-Hellman keys to be at least 1024 bits in size.

Unfortunately Jabber Guest still uses 768bits as the "Server Temp Key" on tomcat. Therefore you can't use Jabber Guest (doesn't matter which version; I tried 10.6.9 and 10.6.10) with Expressway 8.7.2.

I also checked the settings of Tomcat and there is the appropriate setting in /opt/cisco/jabber/conf/mss-sip-stack-properties (which I assume that it is the relevant file):

# support 2048 bits for Ephemeral Diffie-Hellman Keys
jdk.tls.ephemeralDHKeySize=2048

Unfortunately this doesn't work or at least the results are not as expected.

Trying to connect with openssl (openssl s_client -connect <JabberGuestServer>:5061) shows:

-- snip --

Client Certificate Types: RSA sign, DSA sign
Requested Signature Algorithms: ECDSA+SHA512:RSA+SHA512:ECDSA+SHA384:RSA+SHA384:ECDSA+SHA256:RSA+SHA256:ECDSA+SHA224:RSA+SHA224:ECDSA+SHA1:RSA+SHA1:DSA+SHA1:RSA+MD5
Shared Requested Signature Algorithms: ECDSA+SHA512:RSA+SHA512:ECDSA+SHA384:RSA+SHA384:ECDSA+SHA256:RSA+SHA256:ECDSA+SHA224:RSA+SHA224:ECDSA+SHA1:RSA+SHA1:DSA+SHA1
Peer signing digest: SHA512
Server Temp Key: DH, 768 bits
---
SSL handshake has read 3205 bytes and written 210 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA256
Server public key is 4096 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated

-- snip --

Expressway show "dh key too small" in the log-file and "TLS negotiation failure" the when checking the zone status.

It works perfectly with Expressway 8.6.1 (haven't tried 8.7.1 so far).

Log-Files / dumps / Screen-shots are available upon request, but I think the problem is quite clear and hopefully it will be easy to solve.

Thanks and best regards

Wolfgang

That's related to this bug

Jaime Valencia — Tue, 12 Apr 2016 00:36:23 GMT

That's related to this bug

Jabber Guest fails after upgrade from 8.7.1 to 8.7.2

CSCuz13551

You can get in touch with your SE/AM for more details, as it's not publicly visible.

Hi

yjin2 — Tue, 12 Apr 2016 05:03:04 GMT

Could you send me the java version in Jabber Guest server? run this command "

java -version" on Jabber Guest server terminal.

In our lab environment, Jabber Guest(10.6.9 and 10.6.10) works fine with Expressay 8.7.2,Jabber Guest 10.6.9 and above has set the DH key to 1028 bits,connect to our lab Jabber Guest through openssl ,show below info:

--snip----

Client Certificate Types: RSA sign, DSA sign, ECDSA sign

Requested Signature Algorithms: ECDSA+SHA512:RSA+SHA512:ECDSA+SHA384:RSA+SHA384:ECDSA+SHA256:RSA+SHA256:ECDSA+SHA224:RSA+SHA224:ECDSA+SHA1:RSA+SHA1:DSA+SHA1:RSA+MD5

Shared Requested Signature Algorithms: ECDSA+SHA512:RSA+SHA512:ECDSA+SHA384:RSA+SHA384:ECDSA+SHA256:RSA+SHA256:ECDSA+SHA224:RSA+SHA224:ECDSA+SHA1:RSA+SHA1:DSA+SHA1

Peer signing digest: SHA512

Server Temp Key: DH, 1024 bits

---

SSL handshake has read 2626 bytes and written 242 bytes

---

----snip-----

Hi,

WolSen000 — Tue, 12 Apr 2016 06:37:55 GMT

Hi,

thanks for the fast reply.

The java version is:

java version "1.7.0_51"
OpenJDK Runtime Environment (rhel-2.4.4.1.el6_5-x86_64 u51-b02)
OpenJDK 64-Bit Server VM (build 24.45-b08, mixed mode)

The server has been upgraded several times since the initial install, but without any problems so far.

Best regards

Wolfgang

It's really weird, the first

yjin2 — Tue, 12 Apr 2016 07:58:55 GMT

It's really weird, the first official release version of Jabber guest is 10.0 ,I check the java version on Jabber guest 10.0 ,the version is "1.7.0_55".

Where do you get the image for initial install? Have you ever install any external rpm on Jabber guest server ?

PLease Jabber Guest log to us :Cisco Jabber Guest Administration->Logs->Download All

Btw,please run command "rpm -qa" on Jabber Guest server terminal and send us the list.

Thanks

Ok, in this case maybe an

WolSen000 — Tue, 12 Apr 2016 10:30:23 GMT

Ok, in this case maybe an explanation could be that it has been upgraded from the EAP Trial setup.

So the installation base image is/was one of the EAP ova's. Most probably the JabberGuest-10.6.5.65.ova, but I'm not sure at the moment. I'll deploy a new machine later on to investigate.

If that's the cause it might be easier to just reinstall my two JabberGuest servers from a clean-image, I think.

I've attached the output of the "rpm -qa" here, the logs will follow later on.

I haven't installed or changed anything else on the servers beside the original updates.

Sorry to bother you if it's really related to the EAP-Trial installation

Wolfgang

Ok, I did some investigation

WolSen000 — Tue, 12 Apr 2016 14:47:42 GMT

Ok, I did some investigation and I found out that the basic image which was used for the JabberGuest installation must have been a very, very old one (VMware states 1.0.6.101).

I did a fresh install from the JabberGuest-10.6.5.65.ova and checked the Java version there. It was the 1.7.0_75 and the upgrade to JabberGuest-10.6.10.11 performed a rpm-upgrade (never saw that before) which brought Java to 1.8.0_72.

After that the openssl connectivity test shows:

Client Certificate Types: RSA sign, DSA sign, ECDSA sign
Requested Signature Algorithms: ECDSA+SHA512:RSA+SHA512:ECDSA+SHA384:RSA+SHA384:ECDSA+SHA256:RSA+SHA256:ECDSA+SHA224:RSA+SHA224:ECDSA+SHA1:RSA+SHA1:DSA+SHA1:RSA+MD5
Shared Requested Signature Algorithms: ECDSA+SHA512:RSA+SHA512:ECDSA+SHA384:RSA+SHA384:ECDSA+SHA256:RSA+SHA256:ECDSA+SHA224:RSA+SHA224:ECDSA+SHA1:RSA+SHA1:DSA+SHA1
Peer signing digest: SHA512

Server Temp Key: ECDH, P-256, 256 bits

I also did a quick test with an Expressway 8.7.2 and now everything works perfectly.

I deeply apologize for this mistake. I should have checked into this before posting here.

Thanks for your help and best regards

Wolfgang

Hey Everyone,

Brian Pettis — Tue, 12 Apr 2016 19:05:50 GMT

Hey Everyone,

Just hit this issue with a customer and want to provide an update providing clarification. June 2015 OpenSSL 2015 Logjam vulnerability was identified by OpenSSL causing multiple defects filed against Cisco Products that use OpenSSL. Specifics Below:

https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20150612-openssl

https://www.openssl.org/news/secadv/20150611.txt

OpenSSL Security Advisory [11 Jun 2015]
=======================================

DHE man-in-the-middle protection (Logjam)
====================================================================

A vulnerability in the TLS protocol allows a man-in-the-middle
attacker to downgrade vulnerable TLS connections using ephemeral
Diffie-Hellman key exchange to 512-bit export-grade cryptography. This
vulnerability is known as Logjam (CVE-2015-4000).

OpenSSL has added protection for TLS clients by rejecting handshakes
with DH parameters shorter than 768 bits. This limit will be increased
to 1024 bits in a future release.

OpenSSL 1.0.2 users should upgrade to 1.0.2b
OpenSSL 1.0.1 users should upgrade to 1.0.1n

Fixes for this issue were developed by Emilia Käsper and Kurt Roeckx
of the OpenSSL development team.

The specific defect against Jabber Guest is here:

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCuu83421

Starting in JabberGuest 10.6.9 and higher us a 1024 DH Key instead of the 768 DH key size used before 10.6.9. Couple this with the new VCS X8.7.2 also addressing this vulnerability with its CiscoSSL update no longer accepting DH keys smaller than 1024.

www.cisco.com/c/dam/en/us/td/docs/telepresence/infrastructure/vcs/release_note/Cisco-VCS-Release-Note-X8-7-2.pdf#page=3

This issue specifically can occur when during a Call the remote client Bridge or Endpoint requests a FPU(Fast Picture Update) in the form of a SIP INFO message from the JabberGuest client. If the VCS/Exp decides to create a new TCP connection back to JabberGuest on 5061 it will cause a new TLS Handshake to form where JabberGuest is the Server offering DH of 768 causing the DH key size reject. As this new TCP connection isn't always created, meaning the original socket opened from JabberGuest to Expressway, the issue can be see intermittently.

This should clarify the issues being seen between Expressway(VCS) and Jabber Guest where "dh key size too small" error is seen in the Logs, or the behavior of call setup then torn down after a short period of time.

Example of Exp/VCS Logs show DH Key Failure:

2016-04-09T20:05:42+00:00 lslilt01vce tvcs: Event="Outbound TLS Negotiation Error" Service="SIP" Src-ip="192.x.x.x" Src-port="10000" Dst-ip="10.x.x.x" Dst-port="5061" Detail="dh key too small" Protocol="TLS" Level="1" UTCTime="2016-04-09 20:05:42,220"

PCAP from Exp/VCS showing fatal alert on TLS Handshake back to Jabber Guest:

"Alert (Level: Fatal, Description: Handshake Failure)"

The follow command can be used to verify via root from JabberGuest itself or another device such as a VCS that has openssl: <JGIP> being your Jabber Guest server IP (Note 127.0.0.1 from root on JG will not work, must use configured IP of JabberGuest)

openssl s_client -connect <JGIP>:5061 -cipher "EDH" | grep "Server Temp Key"

Further Testing in the Lab:

Jabber Guest 10.6.8 doesn't seem to resolve the issue of the 768 DH Key per lab testing. 10.6.9 however does seem to correct the DH Key to 1024.

NOTE: After performing the upgrade you must reboot the JabberGuest server for the "new" DH key size configuration to take affect.

____________________
LAB RECREATE w/ 10.6.8:

JabberGuest: main_10.6.8.11

From Lab:
[root@jabberguest ~]# openssl s_client -connect 10.x.x.x:5061 -cipher "EDH" | grep "Server Temp Key"
depth=0 CN = localhost.localdomain
verify error:num=18:self signed certificate
verify return:1
depth=0 CN = localhost.localdomain
verify return:1
140461131990856:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:184:
Server Temp Key: DH, 768 bits

____________________
LAB RECREATE w/ 10.6.9:

JabberGuest: main_10.6.9.61

[root@jabberguest cdrom]# openssl s_client -connect 10.x.x.x:5061 -cipher "EDH" | grep "Server Temp Key"
depth=0 CN = localhost.localdomain
verify error:num=18:self signed certificate
verify return:1
depth=0 CN = localhost.localdomain
verify return:1
140392344078152:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:184:
Server Temp Key: DH, 1024 bits

No problem. Good to hear that

yjin2 — Wed, 13 Apr 2016 02:05:16 GMT

No problem. Good to hear that everything can work fine.

Btw,How do you do upgrade from 10.6.5.65 to 10.6.10.11? In our lab environment, the java version in Jabber Guest 10.6.10.11 is

"1.7.0_91", but in your environment ,it is 1.8.0-72.Have you do rpm upgrade manually?

Ok, I just did it again to

WolSen000 — Wed, 13 Apr 2016 07:39:16 GMT

Ok, I just did it again to test/verify.

Use the 10.6.5.65 for a blank install, upgraded to 10.6.10.11 with the upgrade iso file (bash upgrade) and now the server is on "1.7.0_91".

Checking again the server I installed yesterday and this one is also on 1.7.0_91 (which is exactly the version you specified).

Being totally confused I checked the version on my local machine which is, surprisingly 1.8.0_72".

So I must have used the wrong console/terminal accidentally to distinguish the actual java version (reminds me to focus on one task at a time and not too much in parallel).

Anyhow, the server I re-installed yesterday works fine with 8.7.2, so I'm ready to do the upgrade to 8.7.2 again on the upcoming weekend.

Sorry for all the confusion and thanks for your help

Wolfgang

Hey Guys,

Sven Meyer — Fri, 03 Feb 2017 08:05:19 GMT

Hey Guys,

my Jabber Guest Server has a temp Key Size of 786 bit. My JG Version is 11. I reinstalled V11 2 times but the temp key does not change.

Is there an Option to Upgrade the Key manually?

Did you reboot your JG server

niliu2 — Sun, 05 Feb 2017 15:26:09 GMT

Did you reboot your JG server to make the configuration take effect?

If you actually rebooted your server, what's the java version on that server? try command "java -version" in terminal, and let us know (may still use an old JDK version)