[ 
https://issues.apache.org/jira/browse/AMQ-5443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14324275#comment-14324275
 ] 

Timothy Bish commented on AMQ-5443:
-----------------------------------

Now that we require JDK v1.7 a simpler fix might be to use the HTTPS endpoint 
identification algorithm when configuring the SSLParameters.  

{code}
        if (isVerifyHost()) {
            SSLParameters sslParameters = engine.getSSLParameters();
            sslParameters.setEndpointIdentificationAlgorithm("HTTPS");
            engine.setSSLParameters(sslParameters);
        }
{code}

We'd be happy to review a patch along these lines, it should have unit tests 
along with it to validate things work as expected with checking enabled or 
disabled.  

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

Reply via email to