It was reported [1] that Smack (XMPP client library) is vulnerable to MitM attacks with a crafted SSL certificates. Quote from [1]: ... Details ------- Smack is using Java's `SSLSocket`, which checks the peer certificate using an `X509TrustManager`, but does not perform hostname verification. Therefore, it is possible to redirect the traffic between a Smack-using application and a legitimate XMPP server through the attacker's server, merely by providing a valid certificate for a domain under the attacker's control. In Smack versions 2.2.0 to 3.4.1, a custom `ServerTrustManager` implementation was used, which was supplied with the connection's server name, and performed hostname verification. However, it failed to verify the basicConstraints and nameConstraints of the certificate chain (CVE-2014-0363, http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-0363) and has been removed in Smack 4.0.0. Applications using Smack 2.2.0 to 3.4.1 with a custom `TrustManager` did not benefit from `ServerTrustManager` and are vulnerable as well, unless their own `TrustManager` implementation explicitly performs hostname verification. ... [1]: http://seclists.org/bugtraq/2014/Aug/29
Created smack tracking bugs for this issue: Affects: fedora-all [bug 1127277]
References: http://seclists.org/bugtraq/2014/Aug/29 Upstream Issue: https://igniterealtime.org/issues/browse/SMACK-586 Upstream Commits: http://fisheye.igniterealtime.org/changelog/smackgit?cs=057d00c9de04d576db40c4f2525a74dace9580b4
smack-3.2.2-5.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
This issue has been addressed in the following products: Red Hat JBoss Fuse 6.2.0 Via RHSA-2015:1176 https://rhn.redhat.com/errata/RHSA-2015-1176.html