[jira] [Updated] (AMQ-5443) SSL client does not validate server certificate common name

["Allen Hadden (JIRA)" <ji...@apache.org>]

     [ 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)