[
https://issues.apache.org/jira/browse/AMQ-5443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Allen Hadden updated AMQ-5443:
------------------------------
Attachment: MyActiveMQSslConnectionFactory.java
Example workaround connection factory.
> SSL client does not validate server certificate common name
> -----------------------------------------------------------
>
> Key: AMQ-5443
> URL: https://issues.apache.org/jira/browse/AMQ-5443
> Project: ActiveMQ
> Issue Type: Bug
> Components: JMS client
> Affects Versions: 5.10.0
> Reporter: Allen Hadden
> Labels: security
> Attachments: MyActiveMQSslConnectionFactory.java
>
>
> When using SSL the server certificate's common name (or subjectAltName) must
> be validated in order to prevent a man-in-the-middle attack. The ActiveMQ
> client does not do this by default and makes doing so somewhat difficult.
> The result is that most applications that use the ActiveMQ client with SSL
> are not getting the security they think they are. For a very good
> explanation of this hostname verification issue, see
> http://tersesystems.com/2014/03/23/fixing-hostname-verification/
> It is worth nothing that ActiveMQ was specifically mentioned in a paper
> titled "The Most Dangerous Code in the World: Validating SSL Certificates in
> Non-Browser Software" (https://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf):
> "Java-based Web-services middleware, such as Apache Axis, Axis 2, and
> Codehaus XFire, is broken, too. So is the Android library for Pusher
> notification API and Apache ActiveMQ implementation of Java Message Service.
> All programs employing this middleware are generically insecure."
> Also, ActiveMQ is specifically mentioned in CVE-2012-5784
> (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-5784) as an example
> of a library that does not do host name checking. I can't explain why this
> hasn't been a bigger deal (am I missing something?).
> We have worked around this in our code by providing our own connection
> factory class that inherits from ActiveMQSslConnectionFactory. It overrides
> the createTrustManager() and setKeyAndTrustManagers(...) methods in order to
> "decorate" the real TrustManagers with a check for certificate host name.
> Currently, it uses
> org.apache.http.conn.ssl.SSLConnectionSocketFactory.BROWSER_COMPATIBLE_HOSTNAME_VERIFIER
> from the Apache HTTP Client project to verify the host name, which works for
> our project because we already use the Apache HTTP Client elsewhere.
> I created this issue with a Major priority, although it could be argued that
> it's Critical because it's security related and likely to affect so many
> people.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
