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
